@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 fs.exists imho can result in bad user experience for these users.

@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. %APPDATA%). I was trying to comment on your statement:

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.

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.

After taking @bpasero input into consideration it is clear that we can't simply delete workspace storage folders. So we need some UI affordance that point to large workspace storage folders and ask the user whether we should clean it up or not

//cc @egamma @kieferrm

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).