On Fri, Mar 19, 2004 at 09:46:41PM -0801, Jacob Meuser wrote: > 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? It continues to point to "../burn" in this case.
> > 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/? Yes and burn@ remained, continuing to point to "../burn" which is no longer there. > 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. Why would it be undefined? The freebsd symlink(7) page says symlinks are files that act as pointers to other files. What's wrong with moving a file from one place to another? 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. > 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/ > (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.) This is an obvious caveat on any system. > The behaviour of you example is like on Linux. I'm not sure what this means. I have not been able to reproduce the freebsd results on linux or solaris. Cory -- Cory Petkovsek Adapting Information Adaptable IT Consulting Technology to Your (858) 705-1655 Business [EMAIL PROTECTED] www.AdaptableIT.com _______________________________________________ EuG-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
