Set working folder fails

[MH]

We just moved from version 3.0.7 to version 3.1.2. In both versions, (I was hoping 3.1.2 would correct this) if (when setting a working directory) you mark the checkbox labeled "Force all subfolders to use inherited working folder" you are presented with an error:

The process cannot access the file "C:\Documents and Settings\...\CacheMember_WorkingFolderAssignments" because it is being used by another process.

This is happening to all of our machines, it is not machine specific.

I assume that checking this checkbox lets Vault know that you want to recursively create a working folder directory structure that emulates the subfolder directory structure of the Vault directory you are currently marking.

Is this assumption correct? If so, it would appear that vault will do this no matter if the aforementioned checkbox is checked or not. (possibly because of Tools->Options->General->Act on folders recursively is marked.)

Can you shed some light on what's going on???

Thanks,
Mark

[dan]

Yes, the "Force all subfolders to use inherited working folder" option does what you think it should. If you only ever set the top level working folder, then use, this option is not necessary. It is only needed if you have set working folders lower in the tree that you want to clear out.

The error you are getting is a strange one, since it implies that another process has the working folder cache file locked. Do you only get this when the "force" option is on, or do you get it when setting a working folder without the option on? Do you have a lot of Vault processes running?

[MH]

Ok, so it only needs to be checked if you have subfolders that are in this current parent directory that are already set to another working directory? At that point, the subfolders would fall in line with the parent folders working directory structure?

Yes, we only see this error when it is checked. And in fact, when it is checked, after the error is presented, the working folder is set anyway.

An interesting tidbit...

Before we upgraded to 3.1.2, we copied the DB to a temp server and ran the upgrade on the copy (just to make sure the upgrade went smoothly with our DB). When I pointed my 3.1.2 vault client at this instance, I specifically went after this checkbox...to see if it was an upgrade fix. It appeared to work fine (no error). But when we did the real upgrade last night, I hit the checkbox again and the error came up!

There aren't any other processes running that I'm aware of, just the client.

This issue doesn't appear to be a showstopper, but I've been asked about it numberous times by my fellow developers.

Mark

[dan]

Ok, so it only needs to be checked if you have subfolders that are in this current parent directory that are already set to another working directory? At that point, the subfolders would fall in line with the parent folders working directory structure?

Yes, that is correct

Yes, we only see this error when it is checked. And in fact, when it is checked, after the error is presented, the working folder is set anyway.

An interesting tidbit...

Before we upgraded to 3.1.2, we copied the DB to a temp server and ran the upgrade on the copy (just to make sure the upgrade went smoothly with our DB). When I pointed my 3.1.2 vault client at this instance, I specifically went after this checkbox...to see if it was an upgrade fix. It appeared to work fine (no error). But when we did the real upgrade last night, I hit the checkbox again and the error came up!

There aren't any other processes running that I'm aware of, just the client.

This issue doesn't appear to be a showstopper, but I've been asked about it numberous times by my fellow developers.

Mark

That's very strange indeed. Some more questions:

1. Is your folder structure very complicated or contain a lot of shares?

2. Are there generally a lot of working folders defined (e.g., not inherited) when you do this operation?

3. Can you reliably reproduce it?

It's unlikely we'll be able to do much about it unless we can reproduce it here, so any steps that you can provide would be helpful.

[MH]

1. Is your folder structure very complicated or contain a lot of shares?

Doing a Show History... with the Action type of "Share" on the root of our repository returns about 500 files/folders. Our folder structure is broken down by project. We also have a shared directory (at the same level as our projects directory) that contain a number of shares from the projects directory.

2. Are there generally a lot of working folders defined (e.g., not inherited) when you do this operation?

No, in fact, we can reproduce this error 100% of the time even after deleting a client's cache (i.e., no other working folders have been defined).

3. Can you reliably reproduce it?

Like clockwork!

We have another repository set up on this DB...it was set up shortly after we aquired vault. It was created as a sandbox for developers to get used to Vault. It doesn't see much use. Anyway, I logged in to this repository and noticed that the "force..." checkbox works just fine. So it appears to be at the repository level.

Thanks,
Mark

[dan]

I wonder if it is something specific to how that particular repository is setup. Is there anyway we can get a copy of it?

[jclausius]

MH's setup has McAfee anti-virus utility installed on every one of their machines. It seems that McAfee AV is locking some of the Cache files preventing their usage on both the Vault Client and Vault Server, thus causing the file locking errors.

MH was looking into the AV settings to see if there was a way to configure it to ignore the Vault Client cache member and Vault Server temp directories.

[MH]

We were able to set McAfee to ignore a subset of folders on our server and client machines.

Everything is working fine.

I would like to thank the SourceGear support staff for finding the little gremlin (which turned out to be a McAfee issue), we appreciate it!

Mark