Connected: An Internet Encyclopedia
RFC 1813 - 3.3.3 Procedure 3: LOOKUP - Lookup filename

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1813
Up: 3. Server Procedures
Up: 3.3. Procedure Descriptions
Prev: 3.3.2 Procedure 2: SETATTR - Set file attributes
Next: 3.3.4 Procedure 4: ACCESS - Check Access Permission

### 3.3.3 Procedure 3: LOOKUP - Lookup filename

SYNOPSIS

            LOOKUP3res NFSPROC3_LOOKUP(LOOKUP3args) = 3;

            struct LOOKUP3args {
                 diropargs3  what;
            };

            struct LOOKUP3resok {
                 nfs_fh3      object;
                 post_op_attr obj_attributes;
                 post_op_attr dir_attributes;
            };

            struct LOOKUP3resfail {
                 post_op_attr dir_attributes;
            };

            union LOOKUP3res switch (nfsstat3 status) {
            case NFS3_OK:
                 LOOKUP3resok    resok;
            default:
                 LOOKUP3resfail  resfail;
            };

DESCRIPTION

  Procedure LOOKUP searches a directory for a specific name and returns the file handle for the corresponding file system object. On entry, the arguments in LOOKUP3args are:

  what

    Object to look up:

    dir

      The file handle for the directory to search.

    name

      The filename to be searched for. Refer to General comments on filenames on page 30.

  On successful return, LOOKUP3res.status is NFS3_OK and LOOKUP3res.resok contains:

  object

    The file handle of the object corresponding to what.name.

  obj_attributes

    The attributes of the object corresponding to what.name.

  dir_attributes

    The post-operation attributes of the directory, what.dir.

  Otherwise, LOOKUP3res.status contains the error on failure and LOOKUP3res.resfail contains the following:

  dir_attributes

    The post-operation attributes for the directory, what.dir.

IMPLEMENTATION

  At first glance, in the case where what.name refers to a mount point on the server, two different replies seem possible. The server can return either the file handle for the underlying directory that is mounted on or the file handle of the root of the mounted directory. This ambiguity is simply resolved. A server will not allow a LOOKUP operation to cross a mountpoint to the root of a different filesystem, even if the filesystem is exported. This does not prevent a client from accessing a hierarchy of filesystems exported by a server, but the client must mount each of the filesystems individually so that the mountpoint crossing takes place on the client. A given server implementation may refine these rules given capabilities or limitations particular to that implementation. Refer to [X/OpenNFS] for a discussion on exporting file systems.

  Two filenames are distinguished, as in the NFS version 2 protocol. The name, ".", is an alias for the current directory and the name, "..", is an alias for the parent directory; that is, the directory that includes the specified directory as a member. There is no facility for dealing with a multiparented directory and the NFS protocol assumes a hierarchical organization, organized as a single-rooted tree.

  Note that this procedure does not follow symbolic links. The client is responsible for all parsing of filenames including filenames that are modified by symbolic links encountered during the lookup process.

ERRORS

  NFS3ERR_IO NFS3ERR_NOENT NFS3ERR_ACCES NFS3ERR_NOTDIR NFS3ERR_NAMETOOLONG NFS3ERR_STALE NFS3ERR_BADHANDLE NFS3ERR_SERVERFAULT

  SEE ALSO CREATE, MKDIR, SYMLINK, MKNOD, READDIRPLUS, and PATHCONF.

Next: 3.3.4 Procedure 4: ACCESS - Check Access Permission

Connected: An Internet Encyclopedia
RFC 1813 - 3.3.3 Procedure 3: LOOKUP - Lookup filename