在哪个系统/文件系统是os.open（）原子？ [英] On which systems/filesystems is os.open() atomic?

问题描述

这篇文章指出，

  fd = os.open（'foo.lock'，os.O_CREAT | os.O_EXCL | os.O_RDWR）
  

在大多数文件系统上是原子的。这是真的吗（在Unix和Windows上）？在哪个文件系统上？

docs 指出在Unix和Windows上提到的标志是可用的，所以它看起来像一个诱人的跨平台的文件锁定方法（标志 O_CREAT 和 O_EXCL 确保调用进程创建文件）。

解决方案

对于符合UN * X标准的（按照OpenGroup认证的POSIX / IEEE 1003.1）系统，其行为可以通过OpenGroups规范来保证 open（2） 命令这个。引用：
$ b

O_EXCL

如果设置了O_CREAT和O_EXCL，则如果文件存在，则open（）将失败。检查文件是否存在，如果文件不存在，则检查文件的创建，对于执行open（）的其他线程，在O_EXCL和O_CREAT的同一目录中命名相同的文件名应该是 atomic 组。如果设置了O_EXCL和O_CREAT，并且路径名称是一个符号链接，open（）将失败并将errno设置为[EEXIST]，而不管符号链接的内容如何。

公共UN * X和UN * X-如果设置了O_EXCL并且O_CREAT没有设置，结果是未定义的。因为Windows API不包含<$ c $（

$ p $），所以系统（Linux，MacOSX，* BSD，Solaris，AIX，HP / UX） c> open（）就像这样，库函数在本地API方面必须重新实现，但是可以维护语义。

我不知道哪些广泛使用的系统不符合; QNX虽然没有POSIX认证，但在其文档中对于 open（） 。 * BSD manpages没有明确提到原子性，但Free / Net / OpenBSD实现它。即使是像SymbianOS这样的异类（类似于Windows，也没有UN * X-ish 打开系统调用）可以执行原子打开/创建。为了获得更有意思的结果，试着找到一个操作系统/ C运行时库，它有 open（）但是 em>不会 为它实现上面的语义...在哪个Python将与线程运行（有你在那里，MSDOS ...）。

<我的文章特别关注于哪些操作系统对打开？这个特性？ - 答案是几乎所有。 WRT。到 filesystems ，图片是不同的，因为网络文件系统 - 无论NFS，SMB / CIFS或其他，不总是维护 O_EXCL ，因为这可能导致拒绝服务（如果客户端执行打开（...，O_EXCL，...）），然后停止与文件服务器/关闭，其他人将被锁定）。

This article states, that

fd = os.open('foo.lock', os.O_CREAT|os.O_EXCL|os.O_RDWR)

"is atomic on most filesystems". Is that true (on Unix and Windows)? On which filesystems?

The docs state that mentioned flags are available on Unix and Windows, so it looks like a tempting, cross-platform method for file locking (the flags O_CREAT and O_EXCL ensure that the calling process creates the file).

解决方案

For UN*X-compliant (certified POSIX / IEEE 1003.1 as per the OpenGroup) systems, the behaviour is guaranteed as the OpenGroups specs for open(2) mandate this. Quote:

O_EXCL
If O_CREAT and O_EXCL are set, open() shall fail if the file exists. The check for the existence of the file and the creation of the file if it does not exist shall be atomic with respect to other threads executing open() naming the same filename in the same directory with O_EXCL and O_CREAT set. If O_EXCL and O_CREAT are set, and path names a symbolic link, open() shall fail and set errno to [EEXIST], regardless of the contents of the symbolic link. If O_EXCL is set and O_CREAT is not set, the result is undefined.

The "common" UN*X and UN*X-like systems (Linux, MacOSX, *BSD, Solaris, AIX, HP/UX) surely behave like that.

Since the Windows API doesn't have open() as such, the library function there is necessarily reimplemented in terms of the native API but it's possible to maintain the semantics.

I don't know which widely-used systems wouldn't comply; QNX, while not POSIX-certified, has the same statement in its docs for open(). The *BSD manpages do not explicitly mention the "atomicity" but Free/Net/OpenBSD implement it. Even exotics like SymbianOS (which like Windows doesn't have a UN*X-ish open system call) can do the atomic open/create.

For more interesting results, try to find an operating system / C runtime library which has open() but doesn't implement the above semantics for it... and on which Python would run with threads (got you there, MSDOS ...).

Edit: My post particularly focuses on "which operating systems have this characteristic for open ?" - for which the answer is, "pretty much all of them". Wrt. to filesystems though, the picture is different because network filesystems - whether NFS, SMB/CIFS or others, do not always maintain O_EXCL as this could result in denial-of-service (if a client does an open(..., O_EXCL, ...) and then simply stops talking with the fileserver / is shut down, everyone else would be locked out).

这篇关于在哪个系统/文件系统是os.open（）原子？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！