On Fri, Mar 19, 2004 at 05:37:37PM -0800, Cory Petkovsek wrote:

> Here I figured out more specifics.
> linux client/solaris nfs:
> $ ls -l 
> lrwxrwxrwx    1 cory     cory            7 Mar 18 21:31 burn -> ../burn
> drwxr-xr-x    3 cory     cory          512 Mar 19  2004 pub
> $ ls -ld ../burn
> drwxr-sr-x    8 cory     cory          512 Mar 19  2004 ../burn
> $ mv burn pub
> $ ls -l
> drwxr-xr-x    3 cory     cory          512 Mar 19  2004 pub
> $ 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?

> However on freebsd if I type "mv burn/ pub" it moves the target directory, not
> the symlink:
> 
> $ ls -ld ../burn
> drwxr-sr-x  8 cory  10  512 Mar 19 17:21 ../burn/
> $ ls -l
> lrwxrwxrwx  1 cory  10      7 Mar 19 17:22 burn@ -> ../burn
> drwxr-xr-x  3 cory  cory  512 Mar 19 17:30 pub/
> $ mv burn/ pub
> $ ll
> lrwxrwxrwx  1 cory  10      7 Mar 19 17:22 burn@ -> ../burn
> drwxr-xr-x  4 cory  cory  512 Mar 19 17:30 pub/
> $ ls -ld ../burn
> ls: ../burn: No such file or directory

so burn (the directory) moved to pub/?

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.

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

     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.  (Note that if the symbolic link references a
     file via a relative path, moving it to another directory may very well
     cause it to stop working, since the path may no longer be correct.)

The behaviour of you example is like on Linux.

-- 
<[EMAIL PROTECTED]>
_______________________________________________
EuG-LUG mailing list
[EMAIL PROTECTED]
http://mailman.efn.org/cgi-bin/listinfo/eug-lug

Reply via email to