open(9P) - Plan 9 from User Space

From adc93f6097615f16d57e8a24a256302f2144ec4e Mon Sep 17 00:00:00 2001 From: rsc Date: Fri, 14 Jan 2005 17:37:50 +0000 Subject: cut out the html - they're going to cause diffing problems. --- man/man9/open.html | 154 ----------------------------------------------------- 1 file changed, 154 deletions(-) delete mode 100644 man/man9/open.html (limited to 'man/man9/open.html') diff --git a/man/man9/open.html b/man/man9/open.html deleted file mode 100644 index b893119b..00000000 --- a/man/man9/open.html +++ /dev/null @@ -1,154 +0,0 @@ - -open(9P) - Plan 9 from User Space - - - - -

OPEN(9P) OPEN(9P) -

-
-

NAME
- -
- - open, create – prepare a fid for I/O on an existing or new file
- -
-

SYNOPSIS
- -
- - size[4] Topen tag[2] fid[4] mode[1]
- size[4] Ropen tag[2] qid[13] iounit[4] -
- - size[4] Tcreate tag[2] fid[4] name[s] perm[4] mode[1]
- size[4] Rcreate tag[2] qid[13] iounit[4]
- -
-

DESCRIPTION
- -
- - 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 - -
- - -
- - perm & (~0666 | (dir.perm & 0666)) - -
- -
- if a regular file is being created and
- -
- - -
- - perm & (~0777 | (dir.perm & 0777)) - -
- -
- 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. - -
-

ENTRY POINTS
- -
- - 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.
- -
- -

- - -

		-
	- - - -

- - -- cgit v1.2.3