#3004 defect new
FilePath.setContent should do an atomic rename on Windows where possible
|Reported by:||Glyph||Owned by:|
|Cc:||Jean-Paul Calderone, 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
|Summary:||FilePath.setContent should do something correct on Windows → FilePath.setContent should do an atomic rename on Windows where possible|