bug-cvs
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]