Vault client locks local working folder?

[DarrenS]

The use case is this: I currently have the source tree on my local hard drive, under D:\Source say.

I want to get everything fresh (and remove what is currently on my HD beforehand), so I go to D: in Explorer and try to remove the \Source tree. If I happen to have the Vault client running, and the working folder is set to D:\Source, I get an error that the folder is in use. Same thing happens from Command Prompt with rd /q /s. As soon as I close the Vault client I can delete the tree with no problems.

Is this working as designed? It's annoying.

[sterwill]

I'm not sure where the locks are coming from, but I have a theory that it has something to do with .NET garbage collection (someone who knows how FileStream is implemented can surely tell me if I'm wrong).

We don't explicitly lock state files when we load and save working folder state, and we don't keep any files open after we're done. Also, our FileStream objects are used in try/finally blocks, so they're guaranteed to be Close()ed. The FileStreams are always local to the SaveState and LoadState functions, so we don't have any references hanging around. Maybe the FileStream doesn't free all its handles when Close() is called, and it takes a while for the garbage collector to finally release them.

I've seen similar things happen to Word documents after Word was well and truly gone (process not running). After a few minutes, I could delete the document.