bug-cvs
[Top][All Lists]
Advanced

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

Re: cvs has problems using LockDir when CVSROOT holds a symlink


From: Derek Robert Price
Subject: Re: cvs has problems using LockDir when CVSROOT holds a symlink
Date: Wed, 24 Sep 2003 17:28:38 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Jones wrote:

|Derek Robert Price writes [quoting me]:
|
|>Well, having the RCS archive contain the last symlink to a root the file
|>was written with may be a little better in that it gets this correct in
|>more cases.  I suspect that an RCS file should have the canonical root
|>and then any CVS command that prints out the value of the RCS filename
|>should sub in the user specified root.
|
|
|I'm not sure what you mean by that -- the path isn't currently stored in
|the RCS file anywhere that I know of, are you suggesting that we should
|start storing it?


You're correct, it isn't.  I misread Mark's phrasing and took his word
for it when I didn't recall.  Therefore the 1.12.x behavior in regards
to printing the location of RCS archive files is correct and perfect.

|>For unlink, my man page says that unlink conforms to the SVr4, SVID,
|>POSIX, X/OPEN, & 4.3BSD specifications.  Larry, can you tell me if this
|>is a function we can count on?  If we can I think that will take care of
|>unlink_file_dir and deep_remove_dir.
|
|
|"Take care of" in what sense?  unlink doesn't work recursively -- if you
|try to unlink a directory, it either fails or it literally unlinks the
|directory and corrupts the filesystem.  It's also not ANSI C, which has
|remove() instead (with similar limitations).  It should also be noted
|that the current routines honor the noexec flag; if we replace them with
|generic routines, we'll have to be sure to update all the callers to
|check the noexec flag first.


In the sense that if unlink() was portable within our standards, then
unlink_file_dir() and deep_file_remove() wouldn't require any system
dependant code.  I just did some research now that you informed me that
unlink() wouldn't work on directories, however, and I discovered that
there is also an rmdir module in GNULIB, so if unlink was portable and
GNULIB's rmdir is as well, then these two functions could be written
with their system dependant code confined to the rmdir module in
GNULIB.  I was hoping you could tell me if unlink would be portable
enough under our freestanding C89 compiler rules, but the ANSI remove()
function is supplied via <stdio.h>, which is one of the headers we
assume for a freestanding C89 compiler, and should therefore meet our
needs instead.

Derek

- --
~                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
- --
This score just in: OS/2, Windows 95, LinuxPPC 2000.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/cgyFLD1OTBfyMaQRAnYGAKC81Xy2j6ZRkuGxnLnYPxWPSuqs7gCfUyee
2HQqNxaxPigiJEj0nXOr5nQ=
=x0dF
-----END PGP SIGNATURE-----






reply via email to

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