walk(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/walk.html | 119 ----------------------------------------------------- 1 file changed, 119 deletions(-) delete mode 100644 man/man9/walk.html (limited to 'man/man9/walk.html') diff --git a/man/man9/walk.html b/man/man9/walk.html deleted file mode 100644 index 32a72a9e..00000000 --- a/man/man9/walk.html +++ /dev/null @@ -1,119 +0,0 @@ - -walk(9P) - Plan 9 from User Space - - - - -

WALK(9P) WALK(9P) -

-
-

NAME
- -
- - walk – descend a directory hierarchy
- -
-

SYNOPSIS
- -
- - size[4] Twalk tag[2] fid[4] newfid[4] nwname[2] nwname*(wname[s])
- size[4] Rwalk tag[2] nwqid[2] nwqid*(qid[13])
- -
-

DESCRIPTION
- -
- - The walk request carries as arguments an existing fid and a proposed - newfid (which must not be in use unless it is the same as fid) - that the client wishes to associate with the result of traversing - the directory hierarchy by ‘walking’ the hierarchy using the successive - path name elements wname. The fid must represent - a directory unless zero path name elements are specified. -
- - The fid must be valid in the current session and must not have - been opened for I/O by an open or create message. If the full - sequence of nwname elements is walked successfully, newfid will - represent the file that results. If not, newfid (and fid) will - be unaffected. However, if newfid is in use or otherwise illegal, - an Rerror is returned. -
- - The name “..” (dot-dot) represents the parent directory. The name - “.” (dot), meaning the current directory, is not used in the protocol. - -
- - It is legal for nwname to be zero, in which case newfid will represent - the same file as fid and the walk will usually succeed; this is - equivalent to walking to dot. The rest of this discussion assumes - nwname is greater than zero. -
- - The nwname path name elements wname are walked in order, “elementwise”. - For the first elementwise walk to succeed, the file identified - by fid must be a directory, and the implied user of the request - must have permission to search the directory (see intro(9P)). - Subsequent elementwise walks have equivalent - restrictions applied to the implicit fid that results from the - preceding elementwise walk. -
- - If the first element cannot be walked for any reason, Rerror is - returned. Otherwise, the walk will return an Rwalk message containing - nwqid qids corresponding, in order, to the files that are visited - by the nwqid successful elementwise walks; nwqid is therefore - either nwname or the index of the first elementwise - walk that failed. The value of nwqid cannot be zero unless nwname - is zero. Also, nwqid will always be less than or equal to nwname. - Only if it is equal, however, will newfid be affected, in which - case newfid will represent the file reached by the final elementwise - walk requested in the message. -
- - A walk of the name “..” in the root directory of a server is equivalent - to a walk with no name elements. -
- - If newfid is the same as fid, the above discussion applies, with - the obvious difference that if the walk changes the state of newfid, - it also changes the state of fid; and if newfid is unaffected, - then fid is also unaffected. -
- - To simplify the implementation of the servers, a maximum of sixteen - name elements or qids may be packed in a single message. This - constant is called MAXWELEM in fcall(3). Despite this restriction, - the system imposes no limit on the number of elements in a file - name, only the number that may be transmitted in a - single message.
- -
-

ENTRY POINTS
- -
- - Fswalk (see 9pclient(3)) generates walk messages. One or more - walk messages may be generated by any call that evaluates file - names: fsopen, fsopenfd, fsdirstat, fsdirwstat.
- -
- -

- - -

		-
	- - - -

- - -- cgit v1.2.3