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

[Larry Jones]

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?

> |-l tests where the last component of the specified repository is a
> |symlink; it might also be useful to test the case where the symlink
> |appears at a higher level in the path.
> 
> Did you want both tested, or would you consider it sufficient to test a
> single symlinked root with multiple symlinks in the path?  Perhaps
> multiple indirections?  Since the current code never refers to xgetcwd
> but builds the path as it walks it, I thought a single link sufficient,
> but I suppose I may have missed something.

A single root with multiple links is probably sufficient.  I didn't look
at the code, but I know that readlink(), for example, only expands the
last component, so if someone used it incorrectly, it would appear to
work if you only test the last component.

> This is fair enough.  I like the idea of moving as much as possible into
> portable GNULIB-style always-use or AC_REPLACE_FUNC replacement
> functions.  That should be possible for most of the type of thing I
> recall being in filesubr.c but I haven't been through it in awhile.  I
> know I've had to move a function or two from there to src/subr.c in the
> past, I think because I misplaced the function in filesubr.c originally,
> though.

Yes, the name implies that it's subroutines having to do with files, but
it's really system-dependent subroutines (mostly having to do with
files).

> 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.

-Larry Jones

Mom would be a lot more fun if she was a little more gullible. -- Calvin