On Thu, Aug 07, 2008 at 03:38:21PM +0200, Vincent Lefevre wrote:
> retitle 494112 File::Copy::move truncates open file when rename fails
> reassign 494112 perl-modules
> thanks
>
> On 2008-08-07 14:26:07 +0200, Vincent Lefevre wrote:
> > The size of the truncated file appears here. If I understand correctly,
> > the failed rename has truncated the configure.tmp file.
>
> It wasn't truncated, but copied without being flushed first.
> The problem comes from:
>
> if ($atomic_replace && !rename("$output.tmp", "$output")) {
> move ("${output}.tmp", "$output")
> or fatal "cannot rename ${output}.tmp as $output: $!";
> }
>
> in /usr/bin/autom4te. File::Copy::move tries to do a "rename" first.
> If the system call succeeds, no problem. But if it fails (such as with
> sshfs[*]), the file gets truncated.
Frankly, I don't think File::Copy is doing anything wrong.
The documentation specifically says move() will copy the file if rename()
fails, and IMO it's clearly the responsibility of the caller to make
sure the file is closed or at least flushed.
The function doesn't even have any means to flush the file handle, it just
gets the file name. (Well, I suppose it could do something like lsof(8)
does to see if the running process has a file descriptor assigned to
the file, but that's clearly overkill.)
I'll reassign this to autoconf unless convinced otherwise. Just applying
the $out->close patch from Ralf found in this bug log should fix it.
--
Niko Tyni [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
