Front page | perl.perl5.porters |
Postings from November 2011
On Tue, Nov 29, 2011 at 04:27:53PM -0800, James E Keenan via RT <perlbug-followup@perl.org> wrote:
> To my surprise, I get different results on different OSes when I try to
> reproduce this phenomenon. In my case, the two OSes are Linux and Darwin.
Just guessing, but thats probably because linux implements posix rename()
accurately, while some versions of os x are only posix-certified and far
from actually implementing it :)
The relevant posix spec section is, as I know nowadays:
If the old argument and the new argument resolve to the same existing
file, rename() shall return successfully and perform no other action.
that is, if both old and new are hardlinks to the same file, rename just
does nothing, leaving both intact, reporting success. this is not a bug in
the posix spec either, it's really meant to act like that.
silly - one would expect rename to work on filenames.
In any case, since rename is "just" an optimiation, File::Copy ought to
detect that (coreutils mv does it for example, at least when not posixly
correct). Maybe unlinking the from after a successfull rename might do the
trick - I'd rather not think too hard about it.
In any case, rename returning success on a posix system does not mean the
old name has been removed, and thats likely whats happening.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
Thread Next