FilePath.setContent should do an atomic rename on Windows where possible

	@glyph reported
Trac ID	trac#3004
Type	defect
Created	2008-01-22 12:04:16Z

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.

trac-id__3004 3004
type__defect defect
reporter__glyph glyph
priority__normal normal
milestone__ 
branch__ 
branch_author__ 
status__new new
resolution__None None
component__core core
keywords__ 
time__1201003456000000 1201003456000000
changetime__1559919782134300 1559919782134300
version__None None
owner__ 
cc__exarkun cc__Trent.Nelson cc__zooko@... cc__davidsarah

Start at FilePath.setContent and trace its use of Python's os.rename on Windows. Read the referenced MoveFileWithProgress, MoveFileEx, and MoveFileTransacted options, then determine the supported atomic-rename behavior and how failure states should be handled. Done means the Windows implementation avoids deleting the old file before replacement where possible, with the behavior validated by the project's tests.