A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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?
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?
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?
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.
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?
Monday, July 10, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz