Date: Fri, 12 Jan 2001 19:55:53 GMT From: Salvo Bartolotta <bartequi@inwind.it> To: christoph.sold@server.i-clue.de Cc: freebsd-questions@FreeBSD.ORG Subject: Re: mv /a/b/c/ .. Bug? Message-ID: <20010112.19555300@bartequi.ottodomain.org> References: <3A5F40FB.BA91E66A@i-clue.de>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 1/12/01, 6:38:03 PM, Christoph Sold=20
<christoph.sold@server.i-clue.de>
wrote regarding mv /a/b/c/ .. Bug?:
> Hi Folks,
> I just did something unwise:
> # mv /a/b/c/ ..
> Now the c directory is gone completely. Can anybody explain why and
how?
Out of curiosity, I have tried such an operation in... /a/b/c/, where
I had created a very small text file; the move is performed; /a is an
ordinary filesystem.
I have also tried from other (ordinary) paths, just to see if there is
some hidden bug, but I can't find it :-)
On a related note, mv(1) says:
<blockquote>
As the rename(2) call does not work across file systems, mv uses cp(1)
and rm(1) to accomplish the move. The effect is equivalent to:
rm -f destination_path && \
cp -pRP source_file destination && \
rm -rf source_file
</blockquote>
Is there really **complete** equivalence ?
If I consider issuing 'mv /a/b/c/ ..' from /a/b/c/ itself (which I
actually did, see above), then /a/b/c/ should be removed (!), and the
operation should fail... I seem to understand there is a mechanism
which prevents this kind of scr**** ahem error. Maybe the man page
should be slightly modified ? Should I file a PR ? :-)
Best regards,
Salvo
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010112.19555300>