Vault client locks local working folder?

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Posts: 49
Joined: Wed Mar 17, 2004 4:56 pm
Location: Inglewood, CA

Vault client locks local working folder?

Post by DarrenS » Wed Apr 07, 2004 11:10 am

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.

Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Post by sterwill » Wed Apr 07, 2004 12:30 pm

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.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`