Vault Working Folder Problem

Balthazor · Post by **Balthazor** » Tue Dec 19, 2006 3:57 pm

I've seen a strange problem today. I've got a repository folder which shows in the Vault client as having no working folder. I try setting the working folder to the desired local folder and it gives me a message saying that the local folder is already a working folder. Which I've seen before. What's odd is that it shows the local folder is the working folder for the same Vault folder I'm working with.

In other words, suppose my Vault folder is $/Systems/Code, and my local folder is C:\Projects\Code. When I try setting C:\Projects\Code as the working folder for $/Systems/Code, the message tells me that C:\Projects\Code is already assigned as a working folder for $/Systems/Code. Even though Vault shows no working folder assignment.

In addtion, when I use the Vault API to get a list of working folder assignments by means of the client.TreeCache.GetWorkingFolderAssignments, that shows me the working folder assignment. If I look in the CacheMember_WorkingFolderAssignments file, I see the working folder assignment. But Vault shows me no working folder assignment.

However, there's one more thing. using the GetWorkingFolderAssignments function shows some of the working folder assignments being mismatched. That is, if I set local folder A as the working folder for Vault folder A, and set local folder B for Vault folder B, the function shows them reversed: B is assigned to A and A is assigned to B. The CacheMember_WorkingFolderAssignments shows everything correctly, but the function reverses them.

If I delete the CacheMember_WorkingFolderAssignments file and start assigning the working folders from scratch, the same thing ends up happening. If I go to a different workstation and start setting up the working folders, the same thing happens there too.

As far as I can tell, this only occurs for a couple Vault folders. I've tried a bunch of others and they all work just fine. It seems like there's something about these couple of folders which is hosing everything up. It's my understanding that all the working folder assignments are dealt with in the local CacheMember_WorkingFolderAssignments file, that there's nothing about working folder assignment stored in the database. If that's true, then what else might be causing these couple folders to consistently screw up the working folder assignments?

lbauer · Post by **lbauer** » Tue Dec 19, 2006 4:11 pm

Not sure what's going on here. Are your working folder assignments explicitly set or inherited?

Balthazor · Post by **Balthazor** » Tue Dec 19, 2006 4:12 pm

Explicitly set.

Balthazor · Post by **Balthazor** » Wed Dec 20, 2006 10:51 am

Ok, this just keeps getting stranger. We've got an application to build code using the Vault API, and when it runs the SetWorkingFolder function, it brings about the situation I've described. When I set the working folder through the Vault client, it works just fine. So as a test, I threw together another application which sets the working folder on the same Vault folder, exactly as our code builder application does, and that works just fine too. I'm a bit baffled as to how it can work from one application but not from another, since they're doing the exact same thing.

I've run traces on all three: the code builder, the test app, and the Vault client, and the one difference I've seen is that the code bulder, which is what isn't working, results in VaultClientOperationsLib.CacheMember::DeserializeCacheMember being executed. When I set the working folder through the test application and through the Vault client, I'm not seeing this function running. Seems to be the only difference I can see. Of course, I have no idea what that function does or why it would run in one instance and not in the other two.

Balthazor · Post by **Balthazor** » Wed Dec 20, 2006 11:36 am

Eureka! I figured out my problem. There's apparently some case-sensitivity involved in the SetWorkingFolder. The folder name in question is "NAV to AS". The path I was passing into SetWorkingFolder had "NAV To AS". Apparently that really hoses things up.

lbauer · Post by **lbauer** » Wed Dec 20, 2006 1:37 pm

Hm. Seems like there might be a bug here. Could you send us steps to reproduce, so we can fix this?

Balthazor · Post by **Balthazor** » Wed Dec 20, 2006 2:16 pm

Ok. The Vault path I was working with was "$/Systems/HHMI288/ActiveLink/NAV to AS/Department". In my code building application, I ran the TreeCache.SetWorkingFolder passing in a Vault path of: "$/Systems/HHMI288/ActiveLink/NAV To AS/Department". The only difference being the "T" in "To".

Once that's done, the Vault folder shows up in the Vault client as having no working folder assignment. Then in the Vault client, try setting the working folder to the same local folder that you were setting with SetWorkingFolder, you'll get the error:

The following repository path is already assigned to this working folder: $/Systems/HHMI288/ActiveLink/NAV To AS/Department

I'm using Vault version 3.5

lbauer · Post by **lbauer** » Thu Dec 21, 2006 10:13 am

Thanks, we'll try to reproduce this.

lbauer · Post by **lbauer** » Fri Dec 22, 2006 4:28 pm

I did reproduce this.

Thanks for the report. I'll log a bug.

lbauer · Post by **lbauer** » Fri Dec 22, 2006 4:50 pm

BTW: I think the reason you get this error is because there IS a working folder assignment for the subdirectory, Department, but not for Nav To AS

The following repository path is already assigned to this working folder: $/Systems/HHMI288/ActiveLink/NAV To AS/Department