Extension workspaceStorage folder is missing metaData file

[dbaeumer]

Each folder had in the past a meta data file which now seems to be missing.

@bpasero any idea/reason why that got removed. Did it get moved somewhere else?

Not having that file anymore makes it very hard to clean up even with user interaction the workspaceFolder storage.

[bpasero]

@dbaeumer it would help if you could point me to the place where this metadata file is created. I assume it would be close to ExtensionStoragePath?

[dbaeumer]

@bpasero pointed me to that commit: cabd8ad#diff-c61682f360a18cf690ac59fe3f625db7

@jrieken any reason why you removed creating the file ?

[jrieken]

@jrieken any reason why you removed creating the file ?

Sorry, must have been an oversight when doing the sync to async fix. What is the file being used for and what should it contain? I can then bring it back.

[dbaeumer]

The file contained the path to the workspace or workspace file plus the workspace uud. Format was JSON with { workspacePath: string; uuid: string }

[jrieken]

@dbaeumer I have pushed c677bf3 to restore the meta.jon-file creation. Still, we don't have a workspace-path anymore (because it can be many now). Also, with https://github.com//Microsoft/vscode/commit/73dad2ebb9ee82fd40d358fbdf39e1403ced342e @bpasero made the folder be the workspace id. So, with my changes there is no new information as the meta.json basically repeats the name of it's containing folder. Is there anything else you want to have? What will the data be used for?

[dbaeumer]

@jrieken the purpose of the information is to be able to clean old workspace storage information with user interaction and to let users know which storage folders take how much space (both not implemented). So we need to either now the workspace folder or the workspace meta data file location (the .code) file. To my knowledge each multi root workspace gets its own workspace storage location. If a folder in 'mounted' into two multi root workspaces there workspace storage is not shared. @bpasero this is correct?

[jrieken]

So we need to either now the workspace folder or the workspace meta data file location (the .code) file.

Yeah, but you can move that file around and I am not sure what happens then to the workspace... @bpasero will the id stay stable or not?

[jrieken]

@dbaeumer I have pushed a change to also store the workspace name, tho not the path as that information is not available. So, it will look like this

{
  "id": "7b10e36039a1c1cbd389829dfe50ec17",
  "name": "fofof (Workspace)"
}

We could also add the folders of that workspace but that information might change over time...

[bpasero]

@dbaeumer @jrieken each workspace gets its own workspace ID that is derived from the location on disk (single folder: path of folder, workspace: path of workspace config file).

Moving the workspace config file = new ID.

[dbaeumer]

@jrieken @bpasero not having the location on disk will it make very hard for a user to decide if the workspace storage is still needed. We can't even check if the workspace is still available since we don't know where to look. So to implement a user acceptable workspace clean story we would need the location on disk. @bpasero do you store that anywhere and I could then use the ID to get the revers mapping?

[bpasero]

@dbaeumer we have a list of recently opened folders and workspaces, but that one is bounded to 100, so it may not include all entries. And this list can get stale when the workspace was moved.

I suggest to just store the location of the workspace file as meta data and then this could be presented to the user to ask if the storage is still needed. There is a configuration property on the workspace that has the location.

[dbaeumer]

That makes sense to me. So in case of a folder workspace we store the folder location and in case of a workspace with n folder we store the location of the .code file.

@jrieken can you add this

[jrieken]

check

[jrieken]

I have tried to expose the configuration property on IWorkspace which seems to be a little harder....

[bpasero]

@jrieken isn't this just about making configuration optional in IWorkspaceData? Since a workspace can also be a folder without configuration, I think it is fine to do so.

[dbaeumer]

The file now contains

{
  "id": "9a06e95ec93b72725824346f17c608a7",
  "configuration": null,
  "name": "41408"
}

which is IMO not enough information to find the folder on disk. Do I miss something?