[Top][All Lists]

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

Re: symlinks and locks WAS renaming a Repository

From: Derek Robert Price
Subject: Re: symlinks and locks WAS renaming a Repository
Date: Thu, 01 Apr 2004 16:26:28 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

Hash: SHA1

Conrad T. Pino wrote:

>Hi Larry,
>>>Also consider cvs will use repositories identified by symbolic links and
>>Unless you're using LockDir= in your $CVSROOT/CVSROOT/config file, in
>>which case using symlinks will circumvent the locking and corrupt your
>I'd like to understand the symlink and locking issue better because right
>now I'm not sure I understand why locks will fail.  I would appreciate your
>input on the following use cases:

None of the cases you bring up present any locking problems.  There are
only two cases that I am sure have problems:

1)  Links to files in other directories within the repository:

cd $CVSROOT/project/sdir
ln -s ../sdir2/file,v .

In this case, if one CVS server were to attempt to access file,v in sdir
and the other in sdir2, one server would create the lock in sdir and the
other in sdir2, but both would attempt to write the sdir2 file.  This is
arguably a bug since CVS otherwise goes out of its way to handle the
symlink, and I think I may even have seen a recent patch to fix it, but
as far as I know, it hasn't gone in.

2) Links to directories within the repository with LockDir set in

ln -s oldname newname

In this case, when a project is accessed by both oldname and newname,
CVS creates the mirror directory structure in LockDir twice, with
complete trees for both oldname and newname, allowing any number of
directories to be locked twice with all the potential collisions that

And a third possibility just occurred to me, but it wouldn't be able to
cause any actual damage, other than causing processes to loop.  Without
LockDir and with the same dir links as above, if something like a commit
or admin that locked several directories at a time were attempted, if it
attempted to lock _both_ oldname and newname, it could lock one, try and
lock the other, find its own lock, drop its lock, wait 30 seconds and
try again, and so on until it was killed.  I.e., it wouldn't realize
that the lock was its own.


- --

Email: address@hidden

Get CVS support at <>!
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape -


reply via email to

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