This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients David.Townshend, benjamin.peterson, docs@python, neologix, pitrou, vstinner
Date 2011-08-18.11:33:54
SpamBayes Score 2.9168428e-09
Marked as misclassified No
Message-id <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>
The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas:

O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for file I/O).

Probably there are very old systems which don't support it, and perhaps
new systems that don't implement it *correctly* (meaning not
atomically); for the former I'd say we just don't care (who's gonna run
Python 3 on a 1995 system?) and for the latter, well, if the OS
designers think it's fine, let's just expose it as it is.

As for NFS, there's an interesting comment from 2007 here:

“My NFS tester shows that it at least appears to work with Linux,
Solaris and FreeBSD:
http://www.dovecot.org/list/dovecot/2007-July/024102.html. Looking at
Linux 2.6 sources it doesn't look like it tries to implement a racy
O_EXCL check in client side (fs/nfs/nfs3proc.c nfs3_proc_create()), so
the test's results should be correct. I don't know if other OSes do
that. I guess it would be nice to have a better O_EXCL tester which
tries to catch race conditions.”
Date User Action Args
2011-08-18 11:33:56pitrousetrecipients: + pitrou, vstinner, benjamin.peterson, neologix, docs@python, David.Townshend
2011-08-18 11:33:56pitrousetmessageid: <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>
2011-08-18 11:33:55pitroulinkissue12760 messages
2011-08-18 11:33:54pitroucreate