Corrupted files

[DanR]

Client Version 4.2
Server Version 4.2 with Cryptography

We are experiencing a significant number of files that are corrupted as they are written to our local disk from SOS. One or more attempts where we "Get Latest Version" from the SOS client and making sure to select "Force File Transfer", will eventually get us a clean file. Most of these are VB.Net source files in a VS05 IDE but happens to all file types (binary files too).

We were using encryption but turned that off to see if that was an issue but it hasn't seemed to make a difference.

BTW - a "Get Latest Version" executed on a project branch will NEVER get us clean files to overwrite the corrupted ones (there is no "Force File Transfer" option for the branch version of this command!)

[lbauer]

What type of corruption are you seeing in the files?

If you do a get with a VSS client, are the files corrupted?

If you do a Get on the SOS Server itself, using "localhost" for the SOS Server name, are the files corrupted?

[DanR]

If the files are opened with notepad, they look like binary files. Every character of the file is scrambled.

The users on the team using VSS clients have no issues with VSS (no file corruption - but we all have "issues" with VSS!).

I do not have direct access to the VSS/SOS server box so I’m working on that answer for you.

This is a long running project using VSS for several years with the occasional VSS hiccups we have all learned to deal with. We added several developers in a remote location using a Cisco VPN connection to the network. The connection is too slow for VSS client use. My desire was to use Vault, as we do with several other projects, but the decision was to try SOS. A week+ trying to get this working is just getting painful.

We have noticed a pattern. We do a LOT of file sharing between projects. When we do the initial share of a branch (recursive), when the branches/files get shared, files get written to the local drive during the sharing process. These are always all corrupted. If we then delete the local files and do a Get Latest Version from the top level branch, we will usually (not always) get clean files. FYI - These share operations can sometimes share 200 files at a time (so deleting them and getting them again is a slooow process).

I noticed a mention of “some network hardware” can cause issues in other posts. We have a DSL modem and Netgear switch at the remote end, Cisco hardware at the other.

[DanR]

We are not likely to get local access to the VSS box to try an SOS Client on that box ... still working on that.

The VSS API is: SSAPI: 8.0.50727.42

[lbauer]

If the DSL modem, the connection or network was causing the problem, doing the Get from the server machine itself would be a good test.

I'd like to try to reproduce this behavior -- could you give me the steps your are using when you get the corrupt files?

Does this happen on all projects or just certain projects?

[lbauer]

Thanks for the details. We dealt with this offline in case 214333. I wasn't able to reproduce the corruption, but I did some further investigation, and found that we do have a bug logged for this behavior, Work Item 13591.

It is scheduled to be fixed in SourceOffSite 5.0, due out next year. The workaround is to get new copies of the files into the working folder.