<p>It seems there's a second problem too - move on remote file systems use copy rather than rename, so changing the implementation means changing it for copy too, which is more difficult. Maybe the best option is to try to apply some sort of locking mechanism, but I can't see how right now. </p>
<div class="gmail_quote">On Aug 14, 2011 4:01 PM, "Christian Heimes" <<a href="mailto:lists@cheimes.de">lists@cheimes.de</a>> wrote:<br type="attribution">> Am 14.08.2011 08:01, schrieb David Townshend:<br>
>> The latest idea (which I've now described on the issue tracker), is not to<br>>> use os.open(), rather os.link() and os.unlink(), which should work the same<br>>> across platforms. Please could someone correct me if I'm wrong about this.<br>
> <br>> My proposed link() / unlink() procedure works only on platforms and file<br>> systems, that support hard links. I totally forgot about the file system<br>> issue, sorry. :)<br>> <br>> Hard links won't work on a FAT32 mount point on Unix and probably not on<br>
> Samba shares, too. It might work on NTFS if the VFS implements it but<br>> NTFS has a limited reference counter for hard links. It might be<br>> possible that a rename() op would work but a link() op wouldn't.<br>
> <br>> Christian<br>> <br>> _______________________________________________<br>> Python-ideas mailing list<br>> <a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>> <a href="http://mail.python.org/mailman/listinfo/python-ideas">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div>