in reply to Re: Issue with File::Copy and move
in thread Issue with File::Copy and move
I recommend making a full copy, then explicitly deleting the source file only once you've verified the file has been copied to your satisfaction.
That sounds like a good idea. Actually, someone already had exactly that idea. Quoting File::Copy:
move
[...]
If possible, move() will simply rename the file. Otherwise, it copies the file to the new location and deletes the original. If an error occurs during this copy-and-delete process, you may be left with a (possibly partial) copy of the file under the destination name.
Looking at the source, File::Copy::_move(), the backend for File::Copy::move() and File::Copy::mv(), tries really hard to detect and work around OS-specific quirks. On OS/2 and VMS, an existing destination file is deleted first. Then, rename() is tried. If that fails, the fallback code takes over (copy and delete). And only if that fails, the new copy is removed if possible:
# note: $fallback is \&File::Copy::copy() or \&File::Copy::cp() return 1 if rename $from, $to; # Did rename return an error even though it succeeded, because $to # is on a remote NFS file system, and NFS lost the server's ack? return 1 if defined($fromsz) && !-e $from && # $from dis +appeared (($tosz2,$tomt2) = (stat($to))[7,9]) && # $to's the +re ((!defined $tosz1) || # not befo +re or ($tosz1 != $tosz2 or $tomt1 != $tomt2)) && # was + changed $tosz2 == $fromsz; # it's all +there ($tosz1,$tomt1) = (stat($to))[7,9]; # just in case rename did som +ething { local $@; eval { local $SIG{__DIE__}; $fallback->($from,$to) or die; my($atime, $mtime) = (stat($from))[8,9]; utime($atime, $mtime, $to); unlink($from) or die; }; return 1 unless $@; } ($sts,$ossts) = ($! + 0, $^E + 0); ($tosz2,$tomt2) = ((stat($to))[7,9],0,0) if defined $tomt1; unlink($to) if !defined($tomt1) or $tomt1 != $tomt2 or $tosz1 != $ +tosz2; ($!,$^E) = ($sts,$ossts); return 0;
Alexander
|
|---|