open, create – prepare a fid for I/O on an existing or new file|
size Topen tag fid mode|
size Ropen tag qid iounit
size Tcreate tag fid name[s] perm mode
size Rcreate tag qid iounit
The open request asks the file server to check permissions and
prepare a fid for I/O with subsequent read and write messages.
The mode field determines the type of I/O: 0 (called OREAD in
<libc.h>), 1 (OWRITE), 2 (ORDWR), and 3 (OEXEC) mean read access,
write access, read and write access, and execute access, to be
checked against the
permissions for the file. In addition, if mode has the OTRUNC
(0x10) bit set, the file is to be truncated, which requires write
permission (if the file is append-only, and permission is granted,
the open succeeds but the file will not be truncated); if the
mode has the ORCLOSE (0x40) bit set, the file is to be removed
when the fid is clunked, which requires
permission to remove the file from its directory. All other bits
in mode should be zero. It is illegal to write a directory, truncate
it, or attempt to remove it on close. If the file is marked for
exclusive use (see stat(9P)), only one client can have the file
open at any time. That is, after such a file has been opened,
further opens will fail until fid has been
clunked. All these permissions are checked at the time of the
open request; subsequent changes to the permissions of files do
not affect the ability to read, write, or remove an open file.
The create request asks the file server to create a new file with
the name supplied, in the directory (dir) represented by fid,
and requires write permission in the directory. The owner of the
file is the implied user id of the request, the group of the file
is the same as dir, and the permissions are the value of|
if a regular file is being created and
perm & (~0666 | (dir.perm & 0666)) |
if a directory is being created. This means, for example, that
if the create allows read permission to others, but the containing
directory does not, then the created file will not allow others
to read the file.
Finally, the newly created file is opened according to mode, and
fid will represent the newly opened file. Mode is not checked
against the permissions in perm. The qid for the new file is returned
with the create reply message.
Directories are created by setting the DMDIR bit (0x80000000)
in the perm.
The names . and .. are special; it is illegal to create files
with these names.
It is an error for either of these messages if the fid is already
the product of a successful open or create message.
An attempt to create a file in a directory where the given name
already exists will be rejected; in this case, the fscreate call
(see 9pclient(3)) uses open with truncation. The algorithm used
by the create system call is: first walk to the directory to contain
the file. If that fails, return an error. Next walk to the specified
file. If the walk succeeds, send a
request to open and truncate the file and return the result, successful
or not. If the walk fails, send a create message. If that fails,
it may be because the file was created by another process after
the previous walk failed, so (once) try the walk and open again.
perm & (~0777 | (dir.perm & 0777)) |
Fsopen and fscreate (see 9pclient(3)) both generate open messages;
only fscreate generates a create message. The iounit associated
with an open file may be discovered by calling fsiounit.
For programs that need atomic file creation, without the race
that exists in the open−create sequence described above, fscreate
does the following. If the OEXCL (0x1000) bit is set in the mode
for a fscreate call, the open message is not sent; the kernel
issues only the create. Thus, if the file exists, fscreate will
draw an error, but if it doesn’t and the
fscreate call succeeds, the process issuing the fscreate is guaranteed
to be the one that created the file.|