On Sat, Mar 20, 2004 at 12:44:22AM -0800, Cory Petkovsek wrote:
> > > $ ls -l pub
> > > lrwxrwxrwx 1 cory cory 7 Mar 18 21:31 burn -> ../burn
> >
> > so, pub/burn ends up pointing to burn, which does not exist, correct?
> It continues to point to "../burn" in this case.
pub/../burn or pub/../../burn ? It looks like it points to pub/../burn
to me (which doesn't exist), unless linux translates relative links.
> > What's most odd to me is that both scenarios end up with a symlink to
> > nothing. Perhaps the lesson is to not mv a symlink because it's behaviour
> > is undefined ... or at least varies by implementation.
> Only in these scenarios because the symlink is relative. If the symlink was
> absolute, it would have remained valid in both scenarios.
True, but that was not the example.
Why would it be
> undefined? The freebsd symlink(7) page says symlinks are files that act as
> pointers to other files.
Well, it is now pointing to nothing, rather than a file.
What's wrong with moving a file from one place to
> another?
That's pretty general, I can think of lots of situations where it's not
good to move a file, but staying with the discussion, it's because moving
relative symlinks creates confusion.
> The oddity to me is the subtle difference between "mv burn pub" and "mv burn/
> pub" on freebsd produces quite different results, whereas there is no
> distinction on either linux or solaris.
Well, 'something' and 'something/' are different on BSD.
> > symlink(7) on OpenBSD says:
> >
> > If it is explicitly intended that the command operate on the symbolic
> > link instead of following the symbolic link -- e.g., it is desired that
> > ``chown owner slink'' change the ownership of ``slink'', not of what it
> > points to -- the -h option should be used. In the above example, ``chown
> > owner slink'' would change the owner of ``afile'' to ``owner'', while
> > ``chown -h owner slink'' would change the ownership of ``slink''.
> This is good, having a mandatory option to act in a different manner.
>
> > There are several exceptions to this rule. The mv(1) and rm(1) commands
> > do not follow symbolic links named as arguments, but respectively attempt
> > to rename and delete them.
> This is the crux. It is wrong in the case of 'burn/'. The above paragraphed
> is nearly verbatim what the freebsd symlink(7) man page says. I'm curious what
> openbsd's behavior is in this scenario. Please try it:
> cd /tmp ; mkdir a b a/c ; cd a ; ln -s ../b; mv b/ c; ls -l c
>
> On linux/solaris this shows me a link:
> lrwxrwxrwx 1 cory staff 4 Mar 20 00:38 b -> ../b
> On freebsd this shows me a directory:
> drwxr-xr-x 2 cory wheel 512 Mar 20 00:45 b/
On OpenBSD the same as FreeBSD. 's#mv b/ c#mv b c#' and it's the same
as Linux. something != something/
> > The behaviour of you example is like on Linux.
> I'm not sure what this means.
That example behaved the same on OpenBSD as it did for Linux.
> I have not been able to reproduce the freebsd
> results on linux or solaris.
The difference is that in the case of symlinks pointing to directories
('something' as an example), 'something/' points to the directory
rooted in 'something' on BSD, and 'something/' is the same pointer
as 'something' on SysV. On both systems, 'something' has the same
meaning.
--
<[EMAIL PROTECTED]>
_______________________________________________
EuG-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug
