On 06/09/2013 12:50, Richard Oudkerk wrote: > On 06/09/2013 11:23am, Tim Golden wrote: >> On 06/09/2013 11:14, Antoine Pitrou wrote: >>> Le Fri, 06 Sep 2013 08:58:06 +0100, >>> Tim Golden <m...@timgolden.me.uk> a écrit : >>>> >>>> What should Python do? >>> >>> Maybe using FILE_SHARE_DELETE could help? >>> http://bugs.python.org/issue15244 >> >> I don't think so. It's the use of FILE_SHARE_DELETE (by other programs, >> eg Virus Checkers) that typically causes the problem. IOW, the >> sequence is: >> >> * [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other >> programs to delete the file even while this handle is still open >> >> * Python calls DeleteFile -- succeeds if the only open handles are >> FILE_SHARE_DELETE; carries on >> >> * File has apparently disappeared but still has open handles >> >> * Any attempt to create a file of the same name or to delete a >> containing directory fail because the file is still open, even though >> it's successfully been deleted. >> >> * (Some time later) [Some Other Prog] closes its handle and the file is >> now completely gone >> >> >> Unless I'm missing something, there's nothing Python can do to help here >> apart from the sort of delay-retry dance which test.support uses and >> which I'm advocating against as a core feature. > > Instead of deleting, the file could be moved to a temporary name in the > root directory (or some other permanent directory on the same drive) and > then deleted. That would allow the directory to be closed even if a > FILE_SHARE_DELETE handle is still open for the file. >
True, but then you're into determining a temporary name somewhere on the same volume if possible and avoiding collisions etc. Again, I don't think this is something we need to be doing by default in core Python. TJG _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
