Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^2: Writing to a file atomically without renaming

by waswas-fng (Curate)
on Jun 30, 2005 at 20:30 UTC ( #471464=note: print w/replies, xml ) Need Help??

in reply to Re: Writing to a file atomically without renaming
in thread Writing to a file atomically without renaming

If you run out f space n the filesystem you have just clobbered the file. I don't think he is just looking for Atomic write -- but also rollback on err.

  • Comment on Re^2: Writing to a file atomically without renaming

Replies are listed 'Best First'.
Re^3: Writing to a file atomically without renaming
by Transient (Hermit) on Jun 30, 2005 at 20:40 UTC
    Which is why I suggested making the third copy, which could be "rolled back" in case of a problem. It's similar to DB transactions with redo logs. They don't have to worry about the file permissions problems, though.

    eval { copy file to temp_file copy file to backup_file modify temp_file cat temp_file > file verify file is OK remove temp_file and backup_file }; if ( $@ ) { remove temp_file cat backup_file > file remove backup_file }
    Worst case scenario the cat of the backup_file to temp_file fails and you're left with a corrupt "file" and the extra "backup_file" which would have to be moved back manually.
      I think it can be done with three files: the target, a "log" file and a temporary:
      • when starting the program, if the log file exist => cat it to the target and then remove it
      • to modify the file, write the data to a temporary file, them rename the temporary file to be log file, cat the log over the target and finally remove the log file.
      no. worse case is when you are "rolling back" that another user on your multi user system steals the disk space needed for the cat backupfile > file between the time the > zeros file out and the time cat is done -- leaving you with a broken file. That is why the unlink,rename method is popular -- at no time do you destroy the rollback until the new file is in place.

        Your cat must be different than mine..( a cat of a different color?) my "cat backup_file > file" won't destroy both the backup_file and the main file in the event that the backup_file was unable to overwrite the file. A simple diff between the two before removing the backup file is all that would be needed.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://471464]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (1)
As of 2021-09-28 17:57 GMT
Find Nodes?
    Voting Booth?

    No recent polls found