RE: FailFileInvalidChecksum Again!

I speculate that the problem here is that the
cached baseline file inside the _sgvault
folder is damaged.  The most likely cause of
this problem is killing the Vault client, but
there are other possibilities.  Sometimes these
files get accidentally edited, by a global file
system search and replace, for example.

Vault gets very unhappy if these files get
corrupted.  However, I suspect we need to make
Vault handle its unhappiness a bit more
graciously.  We'll check into this.

In the meantime, if I am correct about what your
problem is, deleting the local _sgvault files 
is still the only way to fix it.  However,
you might be able to get away with deleting less
stuff than before, especially if only one or a
few files are causing a problem.  I don't
usually recommend this kind of surgery, but
threatening to go back to VSS indicates you
are obviously a desperate man.  :-)

For the item that's failing, you want to remove
the cached baseline file inside the _sgvault
folder.  cd into that working folder, then
cd into the _sgvault folder inside it.  type
dir.  You should see lots of files with numeric
names such as 1311.46010, and also a file called
"state".

Leave the state file alone.  We'll focus only
on the files which are named with numbers.
For example, looking in one of my own _sgvault
folders, I see the following files:

1315.104670
1315.105950
1315.106834
1315.107570

Each file is named with two numbers.  The first
is the ID of the file.  It is unique for that file,
but is the same for all versions of that file.
The second number is the "VersionID", which is
unique for each version of the file.

In this case, my _sgvault folder contains cached
copies of four versions of this file.

Unfortunately, I don't know which file this is,
and there's no obvious way to tell.

Ideally, you would figure out which files
correspond to the file with the bad checksum.
However, that's fairly tedious.  You can do it
with the Vault command line client.  Its
"listfolder" command reports ID numbers in
the output.  It could also be done by scouting
around the SQL database a bit.

There is one possibly easy way out, if you're
lucky:  If one of these files has zero length,
it is likely to be your culprit.  Delete it.

However, if you don't want to figure out which
file is offensive, you can just delete every
file which begins with a number.  This is a bit
of a sledgehammer approach, but still a lot less
heavy-handed than deleting *all* your working
folders.

cd up one level, back into the directory which
contains your actual working files.  Make a
backup copy somewhere of any file which you've
been editing.  Then open the Vault client and
do a get latest on that folder.  This will force
all the files in the _sgvault folder to be
repopulated.  Put your backup working files
back in place and you should be ready to go
again.

--
Eric Sink
Software Craftsman
http://software.ericsink.com/

 
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Don Kiely
Sent: Monday, January 05, 2004 12:21 AM
To: [email protected]
Subject: [vault-list] FailFileInvalidChecksum Again!

Hi folks,

 

I am once again being plagued by the FailFileInvalidChecksum error, a la:

 

Server unavailable for transaction end

Transaction failed

Item $/AHFC/[blah, blah, blah] caused the transaction to fail: An error
occured during checkin (FailFileInvalidCheckSum).

Transaction failed

 

Eric, this is now happening since I blew away this project on the local
machine and got a fresh copy, and I've not had to end the Vault process
(that I can recall, anyway). And yes, those communication problems with the
server seem to have been resolved.

 

Is there ANY way to get around this without doing that again. It takes
forever to download a fresh copy.

 

If I can't get this solved, I'm going to go screaming into the night and go
back to VSS with SourceOffSite. At least with those I didn't get weird stuff
like this.

 

Thanks (in part in anticipation of a solution and in part for letting me
rant),

Don

 

P.S. Note that in the error message "occured" is spelled wrong. It should be
"occurred" with two r's.