这篇文章指出，
fd = os.open('foo.lock', os.O_CREAT|os.O_EXCL|os.O_RDWR) “在大多数文件系统上是primefaces的”。 这是真的吗（在Unix和Windows上）？ 在哪个文件系统上？
文档中提到的标志在Unix和Windows上是可用的，所以它看起来像是一个诱人的，跨平台的文件locking方法（标志O_CREAT和O_EXCL确保调用进程创build文件）。
对于符合UN * X规范（经OpenGroup认证的符合POSIX / IEEE 1003.1标准的系统）系统，其行为将得到保证，因为OpenGroup规范要求open(2) 。 引用：
O_EXCL
如果设置了O_CREAT和O_EXCL，则如果文件存在，则open（）将失败。 检查文件的存在以及文件的创建（如果文件不存在），对于执行open（）的其他线程来说，它们应该是原子的 ，并且在设置了O_EXCL和O_CREAT的同一目录中命名相同的文件名。 如果设置了O_EXCL和O_CREAT，并且路径名称是一个符号链接，open（）将失败并将errno设置为[EEXIST]，而不管符号链接的内容如何。 如果O_EXCL被设置并且O_CREAT没有被设置，结果是不确定的。
“普通”UN * X和UN * X系统（Linux，MacOSX，* BSD，Solaris，AIX，HP / UX）的行为肯定如此。
由于Windows API本身没有open() ，因此库函数必须在本地API上重新实现，但是可以维护语义。
我不知道哪些广泛使用的系统不符合; QNX虽然没有POSIX认证，但在open()文档中有相同的声明。 * BSD manpages没有明确提到“原子性”，但Free / Net / OpenBSD实现它。 即使像SymbianOS这样的外来物（就像Windows没有UN * X-ISH open系统调用一样）可以做原子打开/创建。
对于更有趣的结果，试着找到一个操作系统/ C运行时库已经open()但没有实现上述的语义…在哪个Python将与线程运行（到你那里，MSDOS … ）。
编辑：我的文章特别关注“哪些操作系统具有这个open特性？” – 答案是“几乎所有”。 WRT。 到文件系统 ，图片是不同的，因为网络文件系统 – 无论是NFS，SMB / CIFS或其他，并不总是维护O_EXCL因为这可能会导致拒绝服务（如果客户端open(..., O_EXCL, ...) ，然后简单地停止与文件服务器/关闭谈话，其他人将被锁定）。