info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File Corruption Problem on Unix


From: Eric Siegerman
Subject: Re: File Corruption Problem on Unix
Date: Wed, 14 Aug 2002 15:40:25 -0400
User-agent: Mutt/1.2.5i

On Wed, Aug 14, 2002 at 01:27:52PM -0400, Brian Robinson wrote:
> Has anyone experienced or heard of the following problem:
> 
> - First we are running CVS 1.11 on Solaris 2.8
> - Desktop checkin/checkout through WinCVS works great
> - Unix checkin/checkout results in problems that show up as file corruption 
> on a machine reboot.  We're trying to pinpoint the commands that might be 
> causing the problem, but here is what we've found so far:
> -- we run some combination of "cvs export -r tag", "cvs checkout module", 
> plus "rm -R *" commands to clean out the working directories.
> -- The next time our Solaris machine reboots, it reports file corruptions 
> that must be cleaned up with fsck.
> -- The fsck activity results in a bunch of lost+found files being created 
> with the timestamp and permissions of the user who was doing the cvs work.
> -- The contents of the lost+found files look like CVS controls information.
>       --- Example: A lot of files contain the strings "Entries", 
> "Entries.log", 
> "Repository", "Root"
>       --- Example: Other files contain list of files in a given directory in 
> the 
> repository
> -- The CVS repository seemed unaffected by these problems -- it's come back 
> clean every time
> -- Some of the file corruption occurs on the boot drive of the unix 
> machine.  We need to clean it up first, then clean up the problems on the 
> filesystem that houses CVS and the CVS work directories.

This doesn't sound like a CVS problem.

What you describe is extremely typical of what happens when a
UNIX system crashes while some program is actively creating or
deleting files.  It just happens that CVS does a lot of that, so
it's not surprising that many of the damaged files have CVS's
fingerprints all over them.  To blame it on CVS, though, is
likely a case of shooting the messenger.

Why is the machine rebooting?  Is someone doing it on purpose, or
is it crashing?  If the latter, well, it shouldn't be; fixing
that will solve the supposed "CVS" problem too.

If it is a purposeful reboot, how is this being accomplished?  If
with "reboot -n" or "-q", there's your problem; get rid of the
option(s).

When is the machine rebooting?  If it's shortly after someone ran
one of those CVS-related commands, all these problems are to be
expected (well, depending on the answers to the questions in the
previous paragraph :-)

If it's a long time after, something else is going on -- the data
should have been flushed to disk by then; that it hasn't been
suggests yet another problem.  (What's the cutoff?  A few seconds
is "shortly"; several minutes is "a long time".  I don't know
enough to pin it down more precisely; someone who knows Solaris
better than I do will have to speak to that.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
        - Paul Schneider-Esleben




reply via email to

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