Subject: Questions about LOOKUP (not fsync :-)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 15 Sep 1999 07:44:37 -0700

It looks like a pathname4 that contains zero components is valid
at least in the xdr sense.  What is appropriate for LOOKUP to 
return here?  I would say INVAL, but an argument could be 
made that this is a no-op if the current file handle is for a
directory.

I have questions about the usefulness of the multi-component
pathname.  If there is any chance that there will be a 
symbolic link for any of the pathnames, this isn't a good
thing to do since all you will get back upon encountering
a symbolic link is NOTDIR (for some component along the way).  
You will then go back and have to do the lookup 
component-by-component.  Since we have COMPOUND, you 
could have done a sequence of LOOKUP's  (each single-
component) interspersed with PUTFH's.  With this sequence, 
if you encounter a symbolic link, you know where it 
happened and can proceed from there.  Given that, is 
anybody going to be using a single LOOKUP with multiple 
path components?  It makes the request and response a 
bit shorter at the cost of more complicated recovery.
Given that there is no latency issue, is this worth it?
If not, how about saving the four bytes on every lookup 
and just make the argument to LOOKUP a component4?

A related suggestion:  How about a new error NFSERR4_SYMLINK
to be used if LOOKUP's current file handle were a symbolic
link instead of returning NOTDIR in this case.  Then the client
could immediately do a READLINK on the appropriate handle
when it got that error back without having to figure out why
it got NOTDIR.

What's the word on zero-length components?  I assume you can't
create them or look them up.  Is this true.  What is the 
approprite error on a CREATE?  Is it just ENOENT on a LOOKUP
or is there some other error.

Given the existence of LOOKUPP, I have questions about the
proper handling of "." and "..".  I know that the client is
supposed to use a LOOKUPP instead of ".." (and a no-op 
instead of "."?), but what is the server supposed to do
about a lookup specifying "." or "..".  Is it just invalid?
Or should systems which traditionally have had . and ..
entries continue to support LOOKUP on them.  Should READDIR
return them as well?  If . and .. entries are returned
by READDIR, I suppose the client can't assume any particular
semantics since here may actually be files (on some servers)
that are named "." or "..".  On the other hand, UNIX 
are going to intercept such names and not typically issue
LOOKUP's using such names so files like that would be 
inaccessible.  There are two ways to deal with this I 
think:

     UNIX . and .. aren't visible over nfs so lookup of
     . and .. return ENOENT, READDIR doesn't report them.
     Other servers may allow . and .. to be created but
     UNIX servers will reject them with some error (which?).
     If a client sees . or .. in a directory it knows it
     can do a lookup using that name.

     UNIX . and .. are visible.  Their appearance are just
     part of UNIX servers' fs semantics although their
     interpretation is not specified by nfs.  UNIX servers
     will support a lookup of . or .. while a client 
     may not depend on it to lookup the current directory
     or the parent.  READDIR does report them.  UNIX
     servers will reject a CREATE with EEXISTS.

Is one of these the right interpretation and if so which
one?  I think I prefer the first, but I'm not sure I've
understand all the implications.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 15 Sep 1999 10:56:46 -0700 (PDT)

> made that this is a no-op if the current file handle is for a

zero length components and zero length pathnames should be INVALs.

> a symbolic link is NOTDIR (for some component along the way). 

Three years ago when I agitated for NFSv4, one of
things I wanted to do that webnfs couldn't was to let clients tell servers to
follow symbolic links on intermediate components of multi-component looks.
lookups. This is possible as long as all intermediate symlinks contain
relative path names.

A UNIX application when it opens "/a/b/c", where

	b --> d

and "/a/d/c" is a regular file, expects

	open("/a/b/c", ...)

to just work. It would be nice if NFS V4's LOOKUP supported this. It
seems like we don't need to add any flags to LOOKUP4args to do so. However,
the draft specification says for READLINK:

     "READLINK reads the data associated with a symbolic link.  The data
     is a UTF-8 string that is opaque to the server.  That is, whether
     created by an NFS client or created locally on the server, the data
     in a symbolic link is not interpreted when created, but is simply
     stored."

It seems that in principle we ought to be able to canonicalize the results of
a READLINK to be a pathname4, such that the client doesn't see a string
separated by slashes or backslashes, and the server instead parses the slashes
(or whatever its operating environment uses as a component separator). 

So if we change READLINK accordingly, given that the introduction
of NFS has discouraged the use of absolute pathnames in the contents
of symbolic links, we should be able to let multi-component LOOKUPs
succeed nearly every time.

But I suspect I'm missing something.

> or is there some other error.

INVAL.

> instead of "."?), but what is the server supposed to do

The client's NFS file system already has ".", so no otw operation is needed.

> about a lookup specifying "." or "..".  Is it just invalid?

It's just invalid. When I first read this, my inclination was
to just declare it as undefined.  But that will lead to lazy implementation
where clients issue "." and "..", servers respond, and neither
correctly implement LOOKUPP.

I suggest the draft specification say:

	A client MUTS not issue a component containing an operating
	environment specific directive to navigate the directory
	hierarchy, such as ".." and "." in the UNIX operating environment.
	If a server receives such a component that is meangingful and specific
	to the environment the server is operating under, then the
	server MUST return INVAL. 

There may be operating environments where "." and ".." are perfectly legal
components, and they have nothing to do with current or parent
directories. In the case, the UNIX client that issues a LOOKUP "." or ".."
expecting to get a currrent or parent directory, will instead get something
else, which is what it deserves.

	-mre