Ensure that this call creates the file: if this flag is specified in conjunction with +o-creat+, and pathname already exists, then open will fail.

When these two flags are specified, symbolic links are not followed: if pathname is a symbolic link, then open fails regardless of where the symbolic link points to.

In general, the behavior of +o-excl+ is undefined if it is used without +o-creat+. There is one exception: on Linux 2.6 and later, +o-excl+ can be used without +o-creat+ if pathname refers to a block device. If the block device is in use by the system (e.g., mounted), open fails with the error +ebusy+.

On NFS, +o-excl+ is only supported when using NFSv3 or later on kernel 2.6 or later. In NFS environments where +o-excl+ support is not provided, programs that rely on it for performing locking tasks will contain a race condition. Portable programs that want to perform atomic file locking using a lockfile, and need to avoid reliance on NFS support for +o-excl+, can create a unique file on the same file system (e.g., incorporating hostname and PID), and use link to make a link to the lockfile. If link returns 0, the lock is successful. Otherwise, use stat on the unique file to check if its link count has increased to 2, in which case the lock is also successful.