O_CREAT
If the file does not exist, it will be created. The owner (user ID) of the file is set to the effective user ID of the process. The group ownership
(group ID) is set either to the effective group ID of the process or to the group ID of the parent directory (depending on filesystem type and mount
options, and the mode of the parent directory; see the mount options bsdgroups and sysvgroups described in mount(8)).
mode specifies the mode to use in case a new file is created. This argument must be supplied when O_CREAT or O_TMPFILE is specified in flags; if
neither O_CREAT nor O_TMPFILE is specified, then mode is ignored. The effective mode is modified by the process's umask in the usual way: in the
absence of a default ACL, the mode of the created file is (mode & ~umask). Note that this mode applies only to future accesses of the newly created
file; the open() call that creates a read-only file may well return a read/write file descriptor.
The following symbolic constants are provided for mode:
S_IRWXU 00700 user (file owner) has read, write, and execute permission
S_IRUSR 00400 user has read permission
S_IWUSR 00200 user has write permission
S_IXUSR 00100 user has execute permission
S_IRWXG 00070 group has read, write, and execute permission
S_IRGRP 00040 group has read permission
S_IWGRP 00020 group has write permission
S_IXGRP 00010 group has execute permission
S_IRWXO 00007 others have read, write, and execute permission
S_IROTH 00004 others have read permission
S_IWOTH 00002 others have write permission
S_IXOTH 00001 others have execute permission
According to POSIX, the effect when other bits are set in mode is unspecified. On Linux, the following bits are also honored in mode:
S_ISUID 0004000 set-user-ID bit
S_ISGID 0002000 set-group-ID bit (see stat(2))
S_ISVTX 0001000 sticky bit (see stat(2))
O_EXCL 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 sym‐
bolic 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 supported only when using NFSv3 or later on kernel 2.6 or later. In NFS environments where O_EXCL support is not provided, pro‐
grams 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 filesystem (e.g., incorporating hostname and
PID), and use link(2) to make a link to the lockfile. If link(2) returns 0, the lock is successful. Otherwise, use stat(2) on the unique file to
check if its link count has increased to 2, in which case the lock is also successful.