Date: Tue, 9 Mar 1999 22:02:51 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, sheldonh@iafrica.com Cc: freebsd-bugs@FreeBSD.ORG, wosch@FreeBSD.ORG Subject: Re: bin/1565 Message-ID: <199903091102.WAA13899@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> (1) $ touch /tmp/z; ln -s /tmp/z ~/z1; mv ~/z1 /tmp/z >> >> where "~" and "/tmp" are not on the same filesystem, causes the >> link to be removed instead of moved. > >Sure, the link is removed, but I haven't lost the referenced file. I >must admit that I can't think of any alternative behaviour that I'd >prefer. What _should_ happen? You should lose the target file in all cases, not just for non-cross device links. >> (2) $ rm /tmp/z; ln -s /tmp/z ~/z1; mv ~/z1 /tmp/z >> >> causes the link to be moved, but then mv(1) emits a bogus error >> message saying that the rename to do the move failed. > >As I understand things, it looks like this: > > ln -s /tmp/z ~/z1 > make ~/z1 a symlink to /tmp/z (which doesn't exist) > > mv ~/z1 /tmp/z > move the symlink ~/z1 to /tmp/z > oops, can't "dereference" ~/z1, spit a warning > >And at that point, you want it to fail, rather than moving the link. >Have I got it straight? I got this slightly wrong. It doesn't cause the link to be be moved. mv just gives up too easily. It should just move the link. Case (1) reduces to case (2) after rm -f'ing the target for the cross- device case as documented in mv.1 (mv should actually rename the target so that it can be restored on error, unless the target is a directory when the move is about to fail unless the source and target are empty directories). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903091102.WAA13899>