[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
cvs repository files being corrupted
From: |
Jeremy Birch |
Subject: |
cvs repository files being corrupted |
Date: |
Thu, 09 Feb 2006 16:00:08 +0000 |
User-agent: |
Thunderbird 1.5 (Windows/20051201) |
Dear CVS,
We have a fairly large CVS repository with a few hundred binary files
and thousands of ascii ones. On a fairly regular basis (and increasingly
over the last month or so) we have noticed repository (*,v) files being
corrupted and thus failing to checkout.
The symptom is that the ,v file has a large amount of NULLs (several
hundred) just after the @@ marker in the file, ie something that should
look a bit like
<snip>
desc
@@
1.69
log
@#3077:UNTESTABLE dont move track unless its width is increasing
@
text
@ <the whole of the HEAD version of this file>
<snip>
looks more like
<snip>
desc
@@
<loads of NULLs>
<the HEAD version missing the first N characters, where N seems to be
roughly the same as the number of NULLs>
<snip>
Obviously this is a real pain, having to retrieve a backed up version
and re-apply whatever changes have got screwed in the meanwhile - this
is doubly a pain for large binary files which seem to be more vulnerable.
We thought initially this was only triggered by tagging, but we have
seen it also happen just on commits of individual ascii files.
The server is on linux, the clients are on linux and XP generally - we
have seen corruption caused by both sets of clients, so the common
factor is the server.
I have looked through the bug email list and the issues fixed in recent
versions and nothing looks like this issue (other than some suggestion
that our machines memory is dodgy which does not convince me).
What it feels like is that locking is failing ie two server processes
are accessing the file at a critical time and the file is truncated (by
the other process) part of the way through the write by the main process
- this gives the packing with NULLs, and the tail of correct data.
Is this a plausible explanation?
Is this a known bug?
How do we fix it?
We are currently using version 1.11.14 for our server, and will be
trying 1.11.21 instead to see if that fixes it, but we can see no entry
in the release notes covering this issue.
Cheers
Jeremy