Subject: RE: Questions about LOOKUP (not fsync :-)

From: "Boris Z." <[email-masked]>
Date: Wed, 15 Sep 1999 11:18:53 -0400

On Wednesday, September 15, 1999 10:45 AM, Noveck, Dave [SMTP:[email-masked]] wrote:
> 
> 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.

It's a good suggestion!

In addition it's good to know what component actually is a symlink.
So may be this error should be accomplished with the corresponding 
part of the multi-component pathname and a FH for it?

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 17 Sep 1999 06:35:36 -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.
> 
> zero length components and zero length pathnames should be INVALs.

That's the way I'm coding it.

> 
> > 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). 
> 
> 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."

This means that the client and the server don't have to agree
on the delimiter but two clients (the one storing and the one
using it) do have to agree.

> 
> 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). 

If you have a canonicalized definition of a symlink (whether to be 
returned by READLINK or used by the server itself), then doesn't
it make sense for the client that creates the link to use that
same format?  In that case, clients that differ on the delimiter
used can still interoperate and the server's pathname delimiter
can be different from either with no problem.  This applies
whether the clients or the server do the symlink interpretation.

By the way, the current spec doesn't seem to have a way to 
create a symlink right now.  Is this really still TBD, or
have I just missed it?

There are two issues (that I know about) with using pathname4
to canonicalize symlinks:

     You have to be able to handle absolute pathnames somehow.
     They may be discouraged but there are still lots of uses
     of them and some of them are even reasonable.

     Need to have a way of handling "..".  Given that dot-dot
     isn't supposed to have a special meaning for LOOKUP, the
     same should apply in this context.

> 
> 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.

We'd have to fail the operation for those with absolute
pathnames, but I guess would still fit in with succeeding
"nearly every time".

If you did this, you would have some interpretation of 
relative symlinks in the server and some in the client,
depending on whether the symlink was encountered on the
last component or not.  It would be nice to allow the
client to request that server do this.  How about a
FOLLOWLINK op.  Given a current fh that is for a 
symlink, set the current file handle to what it 
designates (if it is relative).

> 
> But I suspect I'm missing something.

One issue that I see is handling of strings of dot-dot's.
This may bring you above the mount point (and the server 
doesn't know what the client's mount point is) or even 
above the export point.  The result may not be what it 
would have been on the client which would make it wrong.  
You could not allow crossing of fs boundaries on the server 
but because of the mount point issue this isn't enough.

> 
> > 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.
> 
> INVAL.
> 
> > 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
> 
> 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.
 
I'm assuming that the same applies to trying to create files
named "." and ".." on UNIX servers.  They get INVAL rather
than EEXISTS.  Also, "." and ".." are not going to be returned
by READDIR.  In any case, that's how I'm coding things for now.