FileFailInvalidChecksum

[packinpa]

Am getting the referenced error in the log each time I try to check in a particular file in a project. All other files seem to check-in okay. Would like to know how the simplest way to resolve the checksum error for this one file

[Beth]

The first thing to try is to clear the caches.

On the server, the cache can be cleared by performing an iisreset (Start - Run - iisreset). This will disconnect everyone from the web services, so you may wish to wait for a convenient time.

On the client, first make sure you close Vault and Visual Studio. Then go to %username%\local settings\application data\SourceGear, and drill down until you see a list of cache members. Keep the cache member workingfolderassociation, but delete the rest, and then delete the _sgvault folder. Reopen Vault. You can perform a Get with a Don't overwrite/Merge Later to get it to reset the statuses. After that, return to where you were trying to check in the one file and see if it works.

[ICOM]

I'm running into the same problem (and have run into FailDeltaApply issues in previous versions causing the same symptoms).
We're currently running vault 4.1.0.16216. The changelogs don't report any fixes for this issue, so we haven't upgraded to 4.1.2.

I have followed all of the above steps, as well as performing a "Reset Repository Cache", all without sucess.

Please help!

[Beth]

What types of files are you checking in?

How large are the files?

Are you performing these actions in Vault or in Visual Studio?

[ICOM]

These are various .class.php files all in the same directory and with similar content with sizes near 1kb.

Both the Vault standalone client and the Visual Studio plugin give the same error.

[Beth]

Are all clients experiencing this or just one? Can they work with the same files?

Could you send an email to support at sourcegear.com (attn: Beth) with a link to this thread?

[ICOM]

Just one. Other clients appear to be able to work with these same files.
In the past with the FailDeltaApply error, we would see this same issue, but other clients would eventually run into errors with different sets of files.

And an e-mail is on its way.

[ICOM]

It turns out that a different account on the same machine, with the same working directory is able to check in these modified files. (I literally just left vault open, and chose Connect to Server, and specified a new user's credentials, then set the working directory the same.)

I'm completely baffled as to what difference there could be between a new account in the same copy of vault and an account whose vault client directory has been cleared (except for CacheMember_WorkingFolderAssignments).

[jeremy_sg]

I talked with ICOM on the phone, and the problem has to do with Unknown files and the Override Native EOL setting. The baselines were getting corrupted, and the normal baseline-correction routines were not fixing the problem. 4.1.3 will contain a bug fix for this.