Bug 25013

Summary: mv(1) cannot move unresolvable symlinks across devices
Product: Base System Reporter: mkamm
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.2-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description mkamm 2001-02-11 22:50:01 UTC 
Unresolvable symlinks cannot be moved across devices with mv(1).

Fix: The problem was introduced with a code snippet that protects against
moving mountpoints. Moving mountpoints is bad, because that would
trigger "cp -pRP /mountpoint newname".  My patch invokes this code
snippet only if a directory is to be moved and bypasses it otherwise.
(My patch also tries to avoid redundant lstat(2) calls.)
How-To-Repeat: 
I assume that /tmp and $HOME are on different devices:
$ ln -sf /GENERIC /tmp/generic
$ mv /tmp/generic ~ # this does work

Now I try to move a broken symlink
$ ln -sf /NOSUCH /tmp/nosuch
$ mv /tmp/nosuch ~ # this does work too

Finally I trigger the bug:
$ ln -sf /NODIR/NOFILE /tmp/nofile
$ mv /tmp/nofile ~
mv: cannot resolve /tmp/nofile: /NODIR

Even option -f doesn't help here.
Comment 1 Bruce Evans 2001-02-12 05:18:49 UTC 
On Sun, 11 Feb 2001 mkamm@gmx.net wrote:

> Unresolvable symlinks cannot be moved across devices with mv(1).
> ...
> >Fix:
> 
> The problem was introduced with a code snippet that protects against
> moving mountpoints. Moving mountpoints is bad, because that would
> trigger "cp -pRP /mountpoint newname".  My patch invokes this code
> snippet only if a directory is to be moved and bypasses it otherwise.
> (My patch also tries to avoid redundant lstat(2) calls.)

I think the "protection" should just be removed.  POSIX.2 doesn't
mention a special case for mountpoints (at least least in my old draft
copy that doesn't specify mountpoints :-).  Moving a huge directory
may be a mistake whether or not the directory is a mountpoint.  It is
practically impossible to "protect" against moving mountpoints deep
in the hierarchy.

I think that POSIX.2 and/or BSD made a mistake here, and mv should never
move across filesystems without being forced to.  gnu mv still refuses
to move across filesystems in the last version that I have handy (a
Feb 26 1997 Redhat version running under FreeBSD; this also has emulation
problems -- "mv /tmp/q /usr" attempted to move the directory to
/compat/linux/usr/q).

Bruce
Comment 2 Jaakko Heinonen freebsd_committer freebsd_triage 2010-05-24 16:29:28 UTC 
State Changed
From-To: open->closed

Fixed in r62963.