Re: CVS rtag corrupting files

[Ross Patterson]

On Wednesday 21 May 2003 08:24 pm, Larry Jones wrote:
> Ross Patterson writes:
> > During a "cvs rtag" of a large repository (~131K files, ~1.7GB) that
> > touches almost all of the files, a small number of files are having four
> > bytes of binary zeroes inserted at the start of the file.
>
> You mean there are four NULs at the beginning of the RCS file, just
> before "head"?  

Yes.  And I understand your disbelief, it's astounding to me as well.

> If so, given the way CVS creates and writes RCS files,
> it is not possible for CVS code to be causing this problem; 

Hmm, it seems you're right - the code in rcs.c looks pretty straightforward, 
even given the caching interactions.

> it has to be
> a bug in your C library or OS (on the server -- the client has nothing
> to do with writing RCS files).  

That's kind of hard to believe, given that this server has lots of activity 
and this problem *only* shows up in the CVS repository, and then only when we 
run "cvs rtag".  My first reaction was that it was an underlying-server 
problem, but the symptoms are very specific and they don't show up in any 
other files.  Then again, as Holmes said, "When you have eliminated
the impossible, whatever remains, however improbable, must be the truth."

> If you're really using CVS 1.11.1p1,

Yup, the server is running Red Hat's "cvs-1.11.1p1-3.i386.rpm" package, which 
is 1.11.1p1 plus several patches, none of which affect CVS I/O facilities 
(some authentication stuff primarily).

> that predates the use of mmap(), 

Right, grep doesn't find any mmap hits.

> it has to be a bug in stdio or the underlying I/O routines.  If
> you can reproduce the problem while running CVS under strace (in local
> mode, since the client is irrelevant), that would provide important
> clues as to which it is, although it will probably generate a *lot* of
> trace information.  

I guess I'll give that a shot.  Thanks for the suggestion, and especially for 
ruling out the client-side involvment - that was going to be too much added 
"fun" to debug.

> You also might want to check for known problems with
> the version of Linux you're running on the server.

Problems?  In Linux?  Geez, next thing you'll tell me NFS is buggy too :-)
-- 
Ross A. Patterson
Chief Technology Officer
CatchFIRE Systems, Inc.
5885 Trinity Parkway, Suite 220
Centreville, VA  20120
(703) 563-4164