Re: Remove CVS lock error

[Larry Jones]

Howard Zhou writes:
> 
> It's cvs 1.11 running on Linux and NetBSD build systems. The repository is
> on a netapp server NFS shared.

NFS mounting a repository is a recipe for disaster, especially in a
heterogeneous environment like yours.  We have had numerous reports of
NFS interoperability problems that typically result in the repository
files getting corrupted.  Unfortunately, such corruption can go
unnoticed for a long time, so that by the time you do notice it, you may
well be unable to recover the lost data.  I strongly suggest you set up
some kind of client/server CVS and make the repository local to the
server machine.

> What happens is that two build machines are running update builds with the
> same account meister on two different machines. If two update processes
> owned by the same user running in the same directory at the same time. Both
> processes tried to create #cvs.lock directory. When one process is finished,
> it removed the lock dir. Then the second process tried to remove the lock
> dir but it's gone already.
> 
> Does this explanation make sense?

No.  Only one process should be able to create the lock directory, the
other process should get an error that the directory already exists and
then wait for it to go away before proceding.  The only explanation
would be if *both* processes successfully created the directory, which
implies that your NFS server is *not* creating directories atomically,
which means that CVS locking is not working correctly and YOUR
REPOSITORY IS IN IMMINENT DANGER OF CORRUPTION!

-Larry Jones

OK, what's the NEXT amendment say?  I know it's in here someplace. -- Calvin