Cleanup ExtensionContext.workspaceState when a workspace no longer exists #32461
Comments
|
@dbaeumer how do we know that a workspace no longer exists? Imho just checking for existence of the path is not enough, there may be many users that work via a remote network drive or even a mounted disk where the connection is not always there. Just going by |
|
@bpasero the network drive case is an interesting case I never thought about. We could do the following: if it is a UNC path \...\ and it doesn't exist we leave the workspace storage. Same for a drive letter that doesn't exist. We could prompt the user with a list so that he could clean them manually. |
|
@dbaeumer not sure it is that easy, for example VMs can map a folder into my macOS and this folder is not there if the VM is not started. The path itself does not indicate if it is from a VM/remote or not. |
|
@bpasero I am not sure I fully understand that example. How would the storagePath and the workspace folder be layout in that case. Would the storagePath be inside the VM and the workspace folder location mounted into the VM? |
|
@dbaeumer no, the extension storage will always be on the disk where VS Code is installed (e.g.
On Linux and macOS there are no UNC paths and there are no drive letters. Paths can come and go depending on mounts (e.g. a parallels VM started or stopped), so by just looking at the path you will not be able to find out if the path was deleted or not mounted. |
|
I'd appreciate some options to choose clean up strategies, checking if it exists is fine if you don't use network paths (maybe you could detect if it's a network mount when creating the workspace files in the first place?). If it is a network mount, perhaps just cleaning up LRU (Least Recently Used) would be fine? I just noticed this directory is 35GB on my laptop, with some of the oldest workspaces being nearly a year old and most of them no longer existing (I tend to a roll out a new workspace per feature branch on one project I work on). |
|
cpptools takes 8GB space on my poor C disk. |
|
Could |
|
@bmewburn this is actually a good idea. However it could still lead to disk space consumption if an extension does nothing. |
|
What approach should one take to even manually clean up |
|
I removed a bunch of java plugins but I can still see these extension leftovers Can I manually delete these folders? Will that cause any issues with Code? |
|
seems related to #35006 |
|
I may be wrong but #35006 seems like something for extension authors? I'm curious since i already uninstalled the |
|
How about storing workspaceStorage in the workspace folder instead of the user folder? This way, deleting (or unmounting) the workspace folder will automatically clear the space. |
|
FYI, under linux (and I suppose would work in OSX too) I'm cleaning up the workspace folders pointing non-existing locations with this inline script: for i in ~/.config/Code/User/workspaceStorage/*; do if [ -f $i/workspace.json ]; then folder="$(python3 -c "import sys, json; print(json.load(open(sys.argv[1], 'r'))['folder'])" $i/workspace.json 2>/dev/null | sed 's#^file://##;s/+/ /g;s/%\(..\)/\\x\1/g;')"; if [ -n "$folder" ] && [ ! -d "$folder" ]; then echo "Removing workspace $(basename $i) for deleted folder $folder of size $(du -sh $i|cut -f1)"; rm -rfv "$i"; fi; fi; doneYou can find it somewhat more readable in this gist. |
|
We still have this issue. Today my backup tool was insanely slow and the reason was that I had 70 GB of workspaceStorage in my home directory! Do we have any solution for this issue? I really do not want to add a cleanup script. |
|
Would it be possible to add a window clean up past workspaces and prompt the user for input / selection. There could also be a "wizard" or prompt suggesting which might worth clearing: |
|
@slugmuffin agree that this would be the right way to go. |
|
My VS code workspace storage has reached a ridiculous 150GB
The culprit is vscode cpptools which caches an insane amount per repo |
|
Thanks! |
+1 to this suggestion - just have a .vscodeWorkspaceStorage folder in the workspace instead of storing it elsewhere. In my case workspace storage was just caching information that caused my build to fail. It took me hours to realize that vscode was storing cache data somewhere other than in the workspace directory. 'git clean -fdx' really should have gotten me back to a working state. |
|
@royalpeasantry's suggestion of moving that storage to the actual workspace folder seems like a simple, sensible solution. People do not necessarily expect there to be project data stored elsewhere on the system, and they certainly shouldn't be made to search for where their primary install drive space is going. My case wasn't quite as bad as @mratsim's, but it would have been there soon. I was creating a couple C++ projects a day to work through examples or to test different things, and each one ended up with an ~1GB file from the CPP-TOOLS extension. There was over 100GB of space taken up by these orphaned files before SpaceSniffer was run and that workspaceStorage directory was discovered. While larger SSDs are getting less expensive, that's still a lot of primary install drive space to lose. While both my case and @mratsim's case are related to the CPP-TOOLS extension, this is a problem that really should be fixed in VSCode itself. Enough applications leave orphaned data around as it is, and it appears as if this could be fixed easily enough. Changing the workspaceStorage directory location might be considered "a significant change to VSCode" -- I don't know -- but it would be very useful to have an option for changing where it is located. A simple settings toggle to start using the project's workspace directory for that storage, rather than %APPDATA%\Code\User\workspaceStorage, could do an interim job of fixing the issue. |
just workspace path diferent of ~/.config/Code/User/workspaceStorage/* |
|
After another desperate search to clear up some space on my laptop, I stumbled on a 36GB ConcernIf the proposal to move this data to individual workspace folders was implemented, I worry that it would be less obvious that a rogue extension was eating all my storage. In this case, I would now have 36GB of data scattered about 36 different folders. When considering standalone workspaces setup for each package in our monorepo, and repos spread between my work directory, projects directory, tinkering, etc., I would be hard to see the scale of the problem. Say what you will about having repos in so many different places, but if I were sweeping my HD to clear up space, 1GB wouldn't raise flags (that's entirely normal for ContextI do almost exclusively JS/TS/React programming. Last summer I added PlatformIO and some other extensions to compile firmware for a 3d Printer. I have not touched a CPP file since then, and had largely forgotten about those extensions. When finding these files, my first thought was "I never installed this extension" since IIRC it was installed as a part of the PlatformIO setup process. After deleting the CPP-Tools folders, my ProposalWould it not be better to provide some mechanism for controlling whether an extension will be initialized at all for a given workspace? CPP-Tools seems to be an egregious offender (~1GB per workspace), but might a better solution be to enable Extension Developers to register specific file types which would activate their extension? ExampleA toolkit for Extension Developers would work something like this:
Considerations
|
|
@pdfowler I think it should be reasonable to fill an issue in cpptools to ask them to move cache data closer to a project instead of relying on vscode. Global storage was probably worst idea ever. If ones renames a project folder and reopens it in a vscode the wasted storage is going to multiply significantly. |
|
There is a bunch of related issue concerning moving It's probably good idea to consider other |
|
I've had the same problem and started to develop an extension to solve this problem. Unfortunately I'm not so familiar with the VSCode API (Visualization page, user requests, unit tests, ...), deploying to the marketplace and so. Because of this the development get stucked. Maybe someone else will continue with this as base? The idea of @slugmuffin to present more information to the user and to ask for deletion is much better than my simple implementation. This could be a list with with the information and a check box (to delete or not delete, that's the question) for each workspace closed by common buttons for |
|
Loosely related Stack Overflow question: What are the effects of clearing the workspaceStorage folder for Visual Studio Code? Related extension: |
|
@ThirtySomething There's already an extension that does what you want. (https://marketplace.visualstudio.com/items?itemName=mehyaa.workspace-storage-cleanup) It puts up a list of all the workspaces and provides toggles that select/deselect workspaces based on whether or not they point to non-existent files. There's also a separate toggle for remote workspaces because the check for non-existent files doesn't work the same way. And you can select workspaces manually for deletion. Edit: I missed that starball5 mentioned the same extension. Sorry for the duplication. |
|
@starball5 and also @karl-lunarg thanks for hinting this extension. Didn't know that and haven't found this while I was searching for a solution to this problem. Does exactly what I've planned for my own extension. Great! |
|
Cache cleaning tools should be available as CLI since bloated caches can sometimes prevent starting the GUI. |
|
After restoring a full backup, I realized that the vscode extensions folder consumes 5.6GB. How can it be optimized? Why is it storing all old versions? |
For macOS users replace: |
|
Haven't been using VS Code for years now and can tell you: the problem went away like a charm! Just drop it boys and switch to a brighter side: Neovim. Cheers. |
and others
No description provided.
The text was updated successfully, but these errors were encountered: