Re: [perl #19333] edit <> files in place is not atomic

On Thu, Nov 24, 2011 at 2:30 PM, James E Keenan via RT <
perlbug-followup@perl.org> wrote:

> On Sat Dec 21 10:32:12 2002, eperez wrote:
> > The operation:
> > perl -pi -e 's/foo/bar/' file
> > should be atomic.
> >
> > If something while perl is working hangs the system like a crash or a
> > power failure all the data is lost.
> >
>
> As of Perl 5.14.2, 'pods/perlrun.pod' says this about the '-i' option
> ###
> -i[*extension*]
>  specifies that files processed by the "<>" construct are to be
>  edited in-place. It does this by renaming the input file, opening
>  the output file by the original name, and selecting that output
>  file as the default for print() statements. The extension, if
>  supplied, is used to modify the name of the old file to make a
>  backup copy, following these rules:
>
>  If no extension is supplied, no backup is made and the current file
>  is overwritten.
> ###
>
> This seems to me to guarantee the atomicity the original poster was
> seeking.
>
> Am I correct in this conclusion?  If so, then the ticket may be closed.
>
> Thank you very much.
> Jim Keenan
>

The issue is what happens if the program crashes in the middle of the
operation.  In most OSes* If no extension is supplied and perl dies
unexpectedly, you're out of luck - the original file has been replaced by
whatever perl had managed to write out so far.  The request in this ticket
is to change that to silently using a default extension.  I'd propose a
different solution: update perlrun.pod to point out the following two
caveats if no extension is supplied:

1. If the script dies any time after opening the file, the file will now
only have what had been processed up to that point.
2. Even if no extension is supplied and the file appears to be written in
place, the filesystem doesn't count the space used by the original file as
free until perl exits (or more technically, until the filehandle closes).
I vaguely recall this being brought up as a separate bug on this list,
since it can lead to data loss if the filesystem is close to full.

I'm not sure how much detail to go into in perlrun, otherwise I'd have a
patch attached!

* See http://perldoc.perl.org/perlcygwin.html; Windows does what the
requester wants, with the .bak extension, because it does not support doing
it any other way.  I don't see a note about that in perlwin32.pod, but I
believe it would hold there as well?

• [perl #19333] edit <> files in place is not atomic by James E Keenan via RT
• Re: [perl #19333] edit <> files in place is not atomic by Peter Martini