The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Atomic file updates on Windows

On UNIX, there's an idiom for safe file updates.

Take foo.txt, write a new version of foo.txt called bar.txt. 

Then call fsync() on bar.txt, rename() bar.txt to foo.txt.  Not only is this remarkably reliable, it doesn't disrupt any processes that had foo.txt open.

What's the idiom for doing this on Windows?
Michael B
Saturday, July 08, 2006
Doesn't exactly exist.  Two processes CAN open the same file and read and write to it (look at the share flags with CreateFile), but there is no way that you can swap files out from under a process that has a handle to a file.  Even if you open a file with FILE_SHARE_DELETE, you might be able to delete the file and re-create a new one, but in my experience, the original process still sees the original file contents (I don't think the delete actually completes until all handles to the file are closed).

I'm surprised Unix lets that happen.  Assuming a process could get elevated privileges somehow (and that might be the protection), couldn't OS-level libraries get overwritten this way with a hacked version?
Doug Send private email
Saturday, July 08, 2006
Maybe I wasn't being clear.

Is there a safe way to update a file on a Windows system without risking corrupting it if the program is aborted/system crashes midway?
Michael B
Saturday, July 08, 2006
  On Unix, after the rename, any processes that had the orignal file
open continue to see the original file.  The point of the idiom is that at no time can a process open "foo.txt" and read an incomplete version.  They either get the original, or the *complete* update.
Ernest R. Send private email
Saturday, July 08, 2006
Check out MoveFileEx in the Platform SDK.
Brendan Send private email
Saturday, July 08, 2006
NTFS is a journaling filesystem, so you won't corrupt stuff if power is lost during a copy/move operation.  However, file copy/moves are not transactional, so after restart, the file may or may not have been actually copied to the new location.

There is a chance that someone has written a DTC (distributed transaction coordinator) resource DLL that allows file moves to participate in XA transations, but I don't know of any (google for it?).  In any case, this might add more complexity than you're looking for.

Multi-process access to files is a separate topic, left as an exercise for the reader.
Sunday, July 09, 2006
> NTFS is a journaling filesystem, so you won't corrupt stuff if power is lost during a copy/move operation.

Wait, are you telling me CopyFile is implemented entirely within NTFS's transactional model?  If I CopyFile() a 2GB file and plik reset halfway, there won't be a partial 1GB file in the destination?
Michael B
Monday, July 10, 2006
No, it means that your system will still be bootable afterwards.  Not that your filecopy succeeded. 

Maybe the copy worked, maybe it didn't, depending on the exact sequence of events.
Example Send private email
Friday, July 14, 2006
Isn't there supposed to be a new filesystem in Vista that can enlist in DTC style transactions? TxF or something?
Arethuza Send private email
Monday, July 17, 2006

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz