#3004 defect new
FilePath.setContent should do an atomic rename on Windows where possible
|Reported by:||glyph||Owned by:|
|Cc:||exarkun, Trent.Nelson, zooko@…, davidsarah||Branch:|
It would really be helpful to have someone who knows a lot of Windows stuff look at this ticket and figure out what the right thing to do is.
Using the python stdlib's default os.rename, the right thing to do would be to prefer ending up in a more-consistent state. Currently setContent will delete the old file before moving the new file into place. It might also be advisable to have a "repair" method to complete setContent operations which died after the file was written but before it was moved into place. This should be a separate ticket since UNIX can leave extraneous temporary files around too, but whether it needs to differ per platform depends on whether we can use this:
It looks like the MoveFileWithProgress (or MoveFileEx, or even MoveFileTransacted on Vista) may provide an atomic-rename facility. If we can invoke these without external dependencies it might be better to forego the use of the os module in this case.
Change History (14)
comment:9 follow-up: ↓ 10 Changed 5 years ago by davidsarah
- Cc davidsarah added
- Summary changed from FilePath.setContent should do something correct on Windows to FilePath.setContent should do an atomic rename on Windows where possible