http://www.perlmonks.org?node_id=488861


in reply to Re^2: Perl Best Practices book: is this one a best practice or a dodgy practice?
in thread Perl Best Practices book: is this one a best practice or a dodgy practice?

Which makes it dangerous in the hands of naive users who interrupt a program with CTRL-C, then re-run it. If they do that, they may suffer permanent data loss and without being aware of it.
To quote Oscar Wilde's Miss Prism: "What a lesson for him! I trust he will profit by it." ;-)
It seems to me that you can get re-runnability with little extra effort: simply write the temporary file first and only overwrite the original (via atomic rename) after the temporary has been successfully written.
The IO::Insitu module could certainly be reworked to operate that way. Except that then would fail to preserve the inode of the original file. :-(. Perhaps I will add an option to allow it to work whichever way (i.e. "inode-preserving" vs "rerunnable") the user prefers.

Bear in mind though that an "atomic rename" isn't really atomic under most filesystems, so even this approach still isn't going to absolutely guarantee rerunnability.

Replies are listed 'Best First'.
Re^4: Perl Best Practices book: is this one a best practice or a dodgy practice? (atomic rename)
by tye (Sage) on Sep 03, 2005 at 19:28 UTC
    Bear in mind though that an "atomic rename" isn't really atomic under most filesystems

    rename is atomic on POSIX systems. Win32 has atomic rename and I just checked and rename uses it on modern Win32 operating systems. That qualifies as "most" of the Perl universe in my book (covering the two most common Perl environments, even if TheDamian chooses to call one of the top two "obscure"). Perhaps you have evidence to the contrary or perhaps you are thinking of pre-rename methods using link/unlink?

    - tye        

      My mistake. I hadn't realized we were talking about "atomic rename(1)", rather than more general renaming (such as link/unlink sequences). Sorry for the confusion.