in reply to •Re: Re-runnably editing a file in place
in thread Re-runnably editing a file in place

The script is to run on Windows and various Unix flavours. I suppose I should test $^O to eliminate the unnecessary step on the Unices.

Update. Thanks to merlyn, I have improved my first attempt. On Unix, don't chmod a read-only file because renaming to a read-only file works fine there -- permissions on *directory* (not file) control rename (and delete) on Unix. Permissions now changed on temporary file, not original; this makes the rename the last (atomic) action, making the code 100% rerunnable on Unix, I think. On Windows, there is an extremely low chance of trouble: the rename is right after the chmod(...0200) so the worst that can happen is a read-only file may become writable.

if ($file_contents_changed) {
   my $bak = $fname . $$ . '.tmp';
   -e $bak and (unlink($bak) or die "unlink $bak: $!");
   open(my $fh, '>'.$bak) or die "create $bak: $!";
   print $fh @lines or die "writing $bak: $!";
   close($fh) or die "close $bak: $!";
   defined(my $mode = (stat($fname))[2]) or die "stat $fname: $!";
   chmod($mode, $bak) or die "chmod $bak: $!";
   $^O eq 'MSWin32' && ! -w _ and
      (chmod($mode|0200, $fname) or die "chmod $fname: $!");
   rename($bak, $fname) or die "rename $bak $fname: $!";
}

[download]

Replies are listed 'Best First'.
•Re: Re: •Re: Re-runnably editing a file in place
by merlyn (Sage) on May 22, 2003 at 12:39 UTC
    Oh, so that is a Windows restriction? You're kidding. You can't rename a file you can't read?

    Every time I hear about another way that Windows makes it hard to be a programmer, I thank the maker that I can say no to contracts that have Windows in the specification.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

[reply]

      Let me understand this. I have some data that I wish to keep secret, so I set the file so that only I can read it.

      I come back the next day and discover that my file is missing because although "they" couldn't read it, they could rename it somewhere else in the file system?

      That's logical?

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
[reply]
[reply]

      It's just a paradigm shift. You are used to separating meta-data from data, but many people aren't. On Windows, they try to keep them together.

      For example, this script still has to chase all the meta-data (e.g., chmod, chown) separately. What if there were ACLs? The script needs to be changed yet again to support copying the ACLs. There are downsides to keeping meta-data divorced from data.

      --
      [ e d @ h a l l e y . c c ]

[reply]

      Mea Culpa. The Perl rename function seems to happily clobber a read-only file on Windows.

      Update. The Perl rename function happily clobbers a read-only file on Win98 family but not on WinNT family! Looking at Perl's win32.c, the reason seems to be that MoveFileEx is used under Windows NT, while on Win98 (where MoveFileEx is not available) it deletes the target file before the rename.

[reply]

In Section Seekers of Perl Wisdom