Set Working Folder -> "being used by another process

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Set Working Folder -> "being used by another process

Post by KentPitman » Mon Aug 28, 2006 11:53 am

Doing "Set Working Folder" recursively (by clicking the "force all subfolders" checkbox) on a tree I have set many times now says:

The process cannot access the file "C:\Documents and Settings\kpitman.PTCNET\Local Settings\Application Data\SourceGear\Vault_1\Client\C532E938-0C38-40A9-89A5-77065D789DA9\kpitman\CacheMember_WorkingFolderAssignments" because it is being used by another process.

I have done these things:
- renamed the file in question
- rebooted my machine
- uninstalled and reinstalled Vault
- renamed the indicated file to thatfilename.OLD and let it recreate the file.
- renamed C:\Documents and Settings\kpitman.PTCNET\Local Settings\Application Data\SourceGear to SourceGear.old so that it doesn't even get searched
- renamed HKEY_CURRENT_USER\Software\SourceGear to SourceGear.old
- reinstalled Vault

and the problem STILL persists. I can't figure out what else to try.
The problem is plainly not that another process is locking the same file.
Maybe it's a permissions problem being explained badly?

The strangest thing is that this operation used to work.

The only other factoid that is interesting is that I had my user domain changed recently (from KPitman in the Mathsoft domain to KPitman in the PTCNET domain) and I could imagine that it was looking at some stale data in the C:\Documents and Settings\kpitman\ hierarchy, but I renamed that as well, calling it SourceGear.old instead of SourceGear, so there should not be any conflict. I also don't think I had any open patches at that time nor other state that should have bled through such a change. It mentions the correct part of the Documents and Settings tree in the error message.

Any hints? Any other data I could provide to make this report more intelligible?

I'm running SourceGear Vault Client 3.1.6 (3658) downloaded today.

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Aug 28, 2006 1:06 pm

The first thing I'd probably try is closing vault, clearing your Client Side Cache, then restart Vault and try to set your working folder again.

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Post by KentPitman » Mon Aug 28, 2006 1:17 pm

Beth wrote:The first thing I'd probably try is closing vault, clearing your Client Side Cache, then restart Vault and try to set your working folder again.
Thanks for the suggestion, Beth, but isn't this something I've already tried? That is, didn't I effectively clear it when I said I renamed C:\Documents and Settings\kpitman.PTCNET\Local Settings\Application Data\SourceGear to SourceGear.old ? I did this in both my old and new persona (kpitman and kpitman.PTCNET). Is this renaming I did an ineffective way to clear the cache? I assume it causes SourceGear not to find the cache at all and to recreate everything. I assume it does not nose around in these folders and find them even though they are renamed... Am I wrong? Perhaps there is a preferred way (rather than renaming), but surely this should have worked. I not only closed vault but uninstalled it (which doesn't let you keep vault open when you do it), renamed that folder and renamed all the registry entries, then reinstalled vault, hoping it would start very clean. I also tried restarting the machine.

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Aug 28, 2006 3:14 pm

The file it is referencing in the error you sent me looks to be in the client side cache, which is why I said what I did. Yes, renaming it should have forced it to make a new one unless something else unexplained happened.


With the re-install did you check your registry to make sure that there were not keys hanging around still?
Does this only happen on your client machine, or are any other clients having issues? If this is only happening on your machine, you might want to send me your client side log. You can check here for details on setting that up: http://support.sourcegear.com/viewtopic.php?p=5375
Is the working folder you are trying to use only used for one repository and not shared by multiple people?
Is hierarchy the folder you are trying to set as the working folder?
Have you tried creating a whole new working folder?

Thanks
Beth

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Post by KentPitman » Mon Aug 28, 2006 3:53 pm

Beth wrote:The file it is referencing in the error you sent me looks to be in the client side cache, which is why I said what I did. Yes, renaming it should have forced it to make a new one unless something else unexplained happened.
Ok.
Beth wrote: With the re-install did you check your registry to make sure that there were not keys hanging around still?
Yes, I think so. I first uninstalled. Then renamed the whole key tree. Then reinstalled.
Beth wrote: Does this only happen on your client machine, or are any other clients having issues?
Only on mine.
Beth wrote: If this is only happening on your machine, you might want to send me your client side log. You can check here for details on setting that up: http://support.sourcegear.com/viewtopic.php?p=5375
I'll look into doing this. We're in a deadline frenzy right now so it may have to wait a few days.
Beth wrote: Is the working folder you are trying to use only used for one repository and not shared by multiple people?
Just me.
Beth wrote: Is hierarchy the folder you are trying to set as the working folder?
I couldn't parse this question precisely. The hierarchy I'm trying to set is not shared. It is a tree named Trunk with many subtrees. It is being set to a folder named D:\Trunk on my local disk.
Beth wrote: Have you tried creating a whole new working folder?
No, but that's worth a shot. I have played back and forth with using snapshots in the working folder itself and sometimes not, so there may be some confusion related to that (although the the time the problem originally occurred, I think I was uniformly not using the _sgbak folders in the working area itself. Since then, someone convinced me to change it, but I'm not sure that's relevant other than to say it didn't fix things.
Beth wrote:Thanks
Beth
Thanks for your help. I'll limp along with things for a few days until it's calmer here at the office, then try again.

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Post by KentPitman » Thu Sep 28, 2006 10:58 pm

Beth wrote:The file it is referencing in the error you sent me looks to be in the client side cache, which is why I said what I did. Yes, renaming it should have forced it to make a new one unless something else unexplained happened.
Right.
With the re-install did you check your registry to make sure that there were not keys hanging around still?
This time I did. I cleaned out the registry of SourceGear entries of any kind.
I checked that uninstalling had cleared C:\Program Files\SourceGear. It had.
I checked the Documents and Settings folder, found the SourceGear entry, and removed that.
I deleted the directory I had been checking the stuff out to, and expunged it just in case it was hunting me down in the Recycle Bin to get data it shouldn't.
I rebooted my machine just in case there was an in-memory cache.
I tested this on another machine using my same vault login (though someone else's machine account, which presumably doesn't matter) and it worked fine, so this has to be something about data on my machine that isn't getting wiped, or something else incredibly subtle.
I came back to my machine, with everything wiped clean, and tried it again. Same problem.
I enabled logging, classesToLog set to "all". Problem went away. (Too bad it runs about 20 times as slow with logging on, or I'd just leave it that way.)
I disabled logging. Problem came back.
Just to be sure, I repeated the entire thing: de-installing Vault, wiping the registry, wiping C:\Program Files, wiping C:\Documents and Settings, wiping the checkout directory, re-installing Vault, rebooting.
Problem still there.
Just to be doubly sure, I did it again.
This time I re-enabled logging before I starting Vault for the first time, in case the log might catch something.
Problem happened! No, wait, I forgot to specify a log file. It's supposed to default that, and it has, but it has also defaulted the classes to trace to the empty string, so I got no data. Drat. I guess that means the problem isn't stopped by merely enabling logging, but it matters what I log.
Now I stop the program, set classesToLog to "all", specify another file, and start vault. Again I try the problemsome thing (setting working folder with a recursive checkbox clicked, in case you've forgotten). Now it finally happens. WOW. Was that a lot of work or what??

The process cannot access the file "C:\Documents and Settings\kpitman.PTCNET\Local Settings\Application Data\SourceGear\Vault_1\Client\C532E938-0C38-40A9-89A5-77065D789DA9\kpitman\CacheMember_WorkingFolderAssignments" because it is being used by another process.

I have a log. It looks unexciting. Should I post it as an attachment here or email it to you? It doesn't look to contain any private data, I just don't want to clog your bboard with useless junk.
If you get the log, there's a gap in time between 12:22:11 and 12:34:14 where I wrote this message. During that time, the error message was in display. At 12:34, I dismissed the error message pop-up and shut down the system.
Does this only happen on your client machine, or are any other clients having issues?
As nearly as I can tell, it happens only on this machine.
If this is only happening on your machine, you might want to send me your client side log. You can check here for details on setting that up: http://support.sourcegear.com/viewtopic.php?p=5375
I'll send it when you tell me where.
Is the working folder you are trying to use only used for one repository and not shared by multiple people?
Yes.
Is hierarchy the folder you are trying to set as the working folder?
Can't parse this. There is a folder hierarchy in Vault. I get this whether or not there's no such folder on disk as the one I'm trying to associate or there is a folder hierarchy on disk that I'm trying to associate.
Have you tried creating a whole new working folder?
Yes. I woudn't have thought to but since you asked, I did. No change. Problem still comes back.[/quote]
The only other two pieces of potential clues I can think that are odd about my environment are these:

(1) I mentioned above that our company was purchased and our domain name changed. This affected the location of my Documents and Settings folder, changing my folder name in that hierarchy from kpitman to kpitman.PTCNET. But when I said I've cleared out the SourceGear stuff from that hiearchy, I checked and cleared both. And it's only creating stuff anew in kpitman.PTCNET, so I don't think it's erroneously looking in the old place.

(2) We use an internal hack using the Windows "subst" command that makes "M:" look like a disk. I normally check things out from Vault as D:\Trunk but using subst, I have M: mapped to D:\Trunk ... I don't try to ever talk to Vault about M: because I don't want to confuse it. Sometimes, however, Microsoft Visual Studio notices that I use M: when talking to it (so that I can transparently change where I'm compiling out of) and it gets it in its head that IT wants to talk to Vault. When this happens, I have to go to Vault and say "no, no, don't check things out to M:\ but rather to D:\Trunk ... This is important because while I compile out of several directories that all think they are M:\, I need source control to never get confused about this. But sometimes Studio "helpfully" checks things out for me, and I have to go tell Vault "no, no, don't set the working directory for that file to M, keep it as D:\Trunk." In fact, this is the reason that I need Set Working Directory to work, because I do this all the time after Studio has ever had ahold of my files. And in fact, I've done this for a long time with no trouble. But one day it stopped working, either because of something unrelated or perhaps because I failed to clean up after the mess Studio made. But it may be relevant if Vault thinks it checked out a file to D:\Trunk and then later finds that checkout data says a file named M:\ is there... since they are both the same file. If this is what has happened, it's understandable that this has happened, but I need to know where that data is and I need a way of clearing that data.

I'd also be happy (read: ecstatic) to give Vault a list of files that should be considered the same. e.g, M:\ = D:\Trunk ... This would be helpful if I were using shares, too, since it's often in other programs useful to know that \\Foo\Blah is the same a D:\Blah on some machine where the client is running. And the same comes up for "mapped drives", the other way of assigning a drive letter. (subst seems to be some obscure low-level thing with more capability than the normal GUI interface, and it can map local filenames, not just share names.)

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Fri Sep 29, 2006 7:49 am

You can send the log either using the private function here or to me directly at beth at sourcegear.com and just reference this post.

Can you tell me what version your Vault Server is?

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Post by KentPitman » Fri Sep 29, 2006 8:00 am

Beth wrote:You can send the log either using the private function here or to me directly at beth at sourcegear.com and just reference this post.
Ok. I'll send it momentarily.
Can you tell me what version your Vault Server is?
3.1.6.3658, same as my client.
I'm told we're going to a newer version (not sure which one) in about a week.

mlippert
Posts: 252
Joined: Wed Oct 06, 2004 10:49 am
Location: Cambridge, MA

Post by mlippert » Fri Sep 29, 2006 10:59 am

This is really odd.

I just went over to do a couple more tests on Kent's machine.
  1. Uninstalled Vault from his user
  2. Added a user (me) who had never logged on before as an Administrator
  3. Logged on as the brand new user
  4. Installed Vault Client 3.1.6
  5. Ran Vault Client and logged in as Kent using the repository that's been having problems
  6. Tried to set a working folder specifying Force inherited...
  7. Got the same error
  8. Exited Vault and uninstalled it
Then we logged back on as Kent, and searched the registry for "Sourcegear" and for "Vault", and deleted all entries.
  1. Reinstalled Vault Client 3.1.6
  2. Ran Vault Client and logged in as Kent using a different (and smaller) repository than the one that's been having problems
  3. Checked the Options, saw that Store Working State was set to use the cache location instead of the working folders and changed it to use the working folders
  4. Set the working folder of a couple of folders down the hierarchy w/o specifiying Force Inherited...
  5. Set the working folder of a folder above the previous folders, and specified Force Inherited...
  6. No Error. It worked fine.
  7. Switched to the repository we actually care about
  8. Did the same steps as had just worked, and it Failed in the same way as always (when we specified Force Inherited...)
The working folders we were setting above either didn't exist or were empty in order to avoid possible problems with existing files or _sgvault state files.

Tried 1 more thing.
  1. From Kent's windows user (same as used in the above step)
  2. Logged into Vault with my Vault user instead of Kent's
  3. selected the the problem repository
  4. Attempted to set the working folder and Force Inherited... and it Failed, specifying the cache file created for my user this time
I also tried logging into the Vault client using Kent's Vault user on my machine. That worked with no problems.

I hope you can figure this out, because it is really becoming a problem.

Mike

ps We do have Gold Support, Kent just didn't have the #'s to enable his user for it.

KentPitman
Posts: 10
Joined: Mon Aug 28, 2006 11:24 am
Location: Massachusetts

Post by KentPitman » Fri Sep 29, 2006 11:20 am

mlippert wrote:We do have Gold Support, Kent just didn't have the #'s to enable his user for it.
Ah. Yeah, I didn't realize that was an issue. I've associated my user id with our Gold Support number now, in case that matters. Beth, please let me know if I need to re-post this on the other forum.

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Fri Sep 29, 2006 3:09 pm

I have started rereading this entire thing all over again. I wouldn't expect a domain switch to cause problems, but it really seems tied to that. I will repost soon with some more thoughts on this.

There's no need to repost to another forum at this point. Thanks for letting me know on the Gold Support.

mlippert
Posts: 252
Joined: Wed Oct 06, 2004 10:49 am
Location: Cambridge, MA

Post by mlippert » Fri Sep 29, 2006 3:27 pm

Beth,
I definitely think that the "domain switch" is at the root of these problems.

The domain switch that Kent is talking about was actually a new user, with our MIS department copying over the profile (including the registry User hive) from the old user.

This did cause a whole variety of problems with the Vault Client (ie problems uninstalling it from the new user, when it didn't run), but I was eventually able to get everyone else up and going again, essentially by logging in as the old user and uninstalling Vault and then hunting down other keys in the registry and deleting them, and then re-installing the Vault Client in the new user.

This is not working on Kent's machine. Vault uninstalls and re-installs just fine, but this issue won't go away. He and I (as I mentioned in the previous post) have hunted through the registry to see if there are any keys that we could find that would be Vault related and deleted them.

We've deleted all SourceGear files from Local Settings before re-installing. This problem keeps re-occuring on his machine (and no one else is having this problem).

Mike

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Fri Sep 29, 2006 4:18 pm

No need to repost on the Gold Support.

There just seems to be several variables here.
Domain Change
Additional mapped Hard Drive
Visual Studio integration

I would like to see some items removed from the equation. Would it be possible to unbind those files from Visual Studio and may be even just remove it?
Take the second Hard Drive out of the equation by unmapping and disabling?
Then when you uninstall Vault, remove every thing relating to it at once (cache, working folder, registry entries). I'd check for both Vault and SourceGear. Reboot.
Then do a fresh install of Vault. Before connecting to the server, get the Client side logging going and add in the other options for more detail. Then connect to the server and set a working folder on your C drive with force inheirtance.

If anything goes wrong at that point, then we have the other factors out of the picture. I will want the client log and the server log at that point.

There is one more thing I had found....
Note I found in previous forum post in relation to that error:
The error indicates there are multiple processes trying to access the files. This is frequenty caused by virus scanning software on the machine. Is that a possibility here?

mlippert
Posts: 252
Joined: Wed Oct 06, 2004 10:49 am
Location: Cambridge, MA

Post by mlippert » Mon Oct 02, 2006 8:32 am

Unbinding would be a little insane, there are at least 6 solutions with 10 or more projects in each. In addition, VS isn't running when we have this problem with Vault.

In addition, we did try to remove everything related to Vault the last few times we uninstalled and re-installed it. We even tried this with a brand new never logged on to the computer before user.

The virus scan is a good idea, when the new user was created and the old profile mapped over, MIS also changed the virus software that we run from Norton to McAfee. They might have it set so that it is scanning those files.

I'll try to get the server back in debug log mode soon.

What do you mean by "get the Client side logging going and add in the other options for more detail."?

Mike

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Mon Oct 02, 2006 9:33 am

Details on client-side logging can be found here: http://support.sourcegear.com/viewtopic.php?p=5375

Oh, and the unbinding from VS would only be happening on the one client machine, not with anyone else. VS and Vault can sometimes be looking in different places for their information, which is why I suggested getting it out of the picture for that person.

Post Reply