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)