[EMAIL PROTECTED] wrote: > Tue, Jul 26, 2005 at 01:41:36PM +1000, Steven D'Aprano пишет: > >>Long ago, when dinosaurs roamed the Earth, (a.k.a. >>"before OS X on the Macintosh") Apple suggested a bit >>of Pascal code for safely updating a file: >> >>http://developer.apple.com/documentation/mac/Files/Files-25.html#MARKER-9-163 > > > That snippet doesn't write data to the existing file. It writes data into > the new tempfile and then renames it, as well as the FileInput object does.
Obviously you can't *directly* overwrite a file and expect good things to happen if the disk crashes half-way through. Any sort of safe overwrite must use an intermediate file somewhere. That goes without saying. As for the FileInput object doing the job "as well as" the old Mac file system, no it does not. I've already described how the FileInput object is only usable in a vanishingly small subset of all potential file overwrites, namely when you are writing stdout to the same text file you read from -- or at least one of the multiple files you read from. If that solution works for your needs, you should use it. But if you are not writing to stdout, your data isn't text, and you didn't get it from the same file you are overwriting, the FileInput solution is no solution at all. >>Most of the code is Macintosh-specific, but the >>principle is not: when over-writing a file, make sure >>that the user can recover from any error up to and >>including power failure without losing the data on disk. > > > Well, it's what (R)DBMS are for, but plain files are not. This isn't 1970, users expect more from professional programs than "keep your fingers crossed that nothing bad will happen". That's why applications have multiple levels of undo (and some of them even save the undo history in the file) and change-tracking, and auto-save and auto-backup. Even in the less-than-user-friendly world of Linux many applications implement their own version of data protection. Now maybe you feel that it is overkill for your program to bother about the tiny chance of data loss when saving data. That's fine. For 99% of my scripts, I don't even bother with try...except blocks when writing to a file. I just open it and write to it and hope it all works. But for that other 1%, I take the time to check for errors and allow the program to recover gracefully. And that means, if you are about to save the user's work, you better be sure that if the save fails for any reason, you haven't blown away their precious data. If you want to live dangerously with your own data, go for it. But destroying the user's data is the biggest programming sin of all. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list