<br><br><div class="gmail_quote">On Mon, Aug 15, 2011 at 7:24 PM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I know I'm late to the party, but I'm surprised that the existing<br>
behavior of move() is considered problematic. It carefully mimics the<br>
default behavior of the Unix "mv" command.<br></blockquote><div><br></div><div>But "mv" does allow the "-i" (interactive) and "-n" (no-clobber) arguments, which move() doesn't.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Doing a move or rename atomically with the provision that it fails<br>
reliably when the target exists might be useful in some cases, but it<br>
seems to be more related to filesystem-based locking, which is known<br>
to be hard in a cross-platform way. (It also seems that some folks on<br>
the thread have ignored Windows in their use of the term<br>
"cross-platform".)</blockquote><div><br></div><div>That's certainly what I've found in trying to do it! But it seems that it should be possible on most systems, just each in a different way.  On windows, it should be as easy as trying os.open(file, os.O_EXEC|os.O_CREAT) first since windows appears to lock a file to a process when its opened.  Linux ext file systems (arguably the most common) support an immutable attribute, also effectively locking the file.  I think that reiserFS and XFS both has similar features.  Unfortunately I have no experience with OSX or HPFS so I'm not sure how it would work on a Mac.</div>
<div><br></div><div>This is quite a lot to implement though, so whether its worth it is another matter... especially since it would be far easier (although slower) to just copy/remove if it really is a problem.</div></div>