From: Noveck, Dave (dave.noveck@netapp.com)
Date: 09/15/99-09:44:37 AM Z
Message-ID: <7F608EC0BDE6D111B53A00805FA7F7DA05D10C24@TAHOE>
From: "Noveck, Dave" <dave.noveck@netapp.com>
Subject: Questions about LOOKUP (not fsync :-)
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.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:35 AM Z CST