Vault Get does not return file from repository

[sgclark]

Had a strange problem today with Vault (ver 6.1.0 (531)). A file retrieved from Vault by a build server was found to be truncated. I looked at the file in the repository and it had correct contents. When I did a get of the file using the Vault client to the working directory, about 2/3 of the content ( a VB source file) was missing. Get with overwrite did the same thing. I then did a Get of the file to the Windows desktop and the complete file was retrieved. I copied this complete file to the correct working folder and the Show Differences in the Vault client showed the working the working version was missing the same 2/3 of the content. Since this made no sense to me, I figured I'd try removing the cache files. Once the the cache files were removed, everything working fine, the file retrieved by the Get was now correct.

I'm more than a little concerned that it seems that doing a Get from the repository does NOT seem to get the file from the repository, but rather from the cache. How can we force the Get to get a file from the repository? How can we trust that the files retrieved by a Get are correct if a corrupted cache can interfere? Secondly, is there an easy way (through the UI) to clear or turn off the cache?

Steve

[Beth]

What OS is your build server on?

Are you running a Vault GUI client right on the build server too, or was the GUI client on a different machine?

Are any Gets to a mapped drive?

Check your Vault server log on the Vault server at %windir%\temp\sgvault\sgvault.log. Does it have any errors during the time the the Gets were failing?

[sgclark]

What OS is your build server on? <XP Sp3>

Are you running a Vault GUI client right on the build server too, <Yes> or was the GUI client on a different machine?<No>

Are any Gets to a mapped drive? <No>

Check your Vault server log on the Vault server at %windir%\temp\sgvault\sgvault.log. Does it have any errors during the time the the Gets were failing? <See attached file>

Thanks,
Steve

[Beth]

Can you also post the VaultGUIclient.txt from the machine found in %temp%?

[sgclark]

I've attached a zipped copy of the file you requested. The exceptions in the file don't appear to relate to the file that was truncated.

Thanks,

Steve

[Beth]

What build system are you using?

Do you have the option to set up a queue?

[sgclark]

Using CCNet to build and test four projects. Two of the projects are checkin-builds; they are on the same queue and build all the assemblies and run a subset of our tests. The other two projects are nightly integration builds and they are on another queue and build all the assemblies and run all of our tests, including end-to-end testing with a database.

Steve

[Beth]

The errors in the sgvault.log suggest to me that a connection to the SQL Server closed before it could roll back a failed transaction, but nothing was mentioned about what failed. If the SQL connection is closing during a Get, that would prevent all the deltas from being retrieved for them to be applied to the file.

Why I asked about the build system and queues, is that similar errors happened for a user that wasn't using a queue. Since you have those, that helps cut down on possible causes.

Before any of this were there any network outages? If the cache was trying to update and the network went down, then the cache would have been missing some data.

[sgclark]

There were no network outages that I'm aware of during that period, but I'll check with our network admins to make sure.

Even with a corrupt cache, why didn't doing a Get with the overwrite option overwrite the local file with the latest version of the contents of the repository file instead of the cached version? I thought a Get gets the files from the repository? Is there another way to force Vault to use the repository rather than the cache?

[Beth]

UPDATE:
If the cache has the exact file and the particular version of that file, then it will get it from the cache.

If the cache is modified directly, then that will cause problems. Make sure no working folders are pointing to the cache or that no editing of any cache files is happening.

You also need the cache for helping Vault determine what to upload on check in. Vault compares what is in the working folder to the cache and creates a delta based on that comparison. Then on check in, only the delta is checked in.

What you might try is going to Vault - Tools - Options - Local Files - Cache Location. There is a button there called Reset Repository Cache. Click that button and then try your Get.

[sgclark]

Thanks for the tip on the Reset Repository Cache option.

It seems then that the only way to guarantee that a Get gets files from the repository and not the cache is to reset the cache first?

Thanks for your help on this, Beth. Hopefully this was just a random glitch. Still, I think it might make sense to have an option on the Get Latest Version Dialog to update or refresh the cache files.

Steve

[Beth]

One way to guarantee that the cache isn't looked at is to Get to a non-working folder. Non-working folders are not tracked.