glenda.party
term% ls -F
term% pwd
$home/manuals/9front/5/walk
term% cat index.txt
WALK(5)                       File Formats Manual                      WALK(5)



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 el‐
       ements 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 proto‐
       col.

       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 equiva‐
       lent 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, ``element‐
       wise''.  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(5)).  Subsequent el‐
       ementwise  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  re‐
       turned.   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 equiva‐
       lent 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(2).  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
       A call to chdir(2) causes a walk.  One or more  walk  messages  may  be
       generated  by  any  of  the following calls, which evaluate file names:
       bind, create, exec, mount, open, remove,  stat,  unmount,  wstat.   The
       file  name element .  (dot) is interpreted locally and is not transmit‐
       ted in walk messages.



                                                                       WALK(5)