Subject: Re: Why LOOKUPP

From: Brent Callaghan <[email-masked]>
Date: Thu, 23 Sep 1999 08:35:28 -0700 (PDT)

> I don't see any need for the LOOKUPP operation.
> 
> Is the purpose of this to keep the client from having to 
> cache the filehandle for each path elemnt?

Yep.  It's quite possible that a client could use a multi-component
lookup to get to a directory without receiving filehandles for
any of the intermediate components.  The LOOKUPP let's the client
walk back up the tree on the server.

LOOKUPP is just a formalization of the LOOKUP ".." that is described
in NFS v2 & v3.

> This is an operation the a lot of filesystems will have a hard time
> dealing with.  They just don't have parent directories.

I'm not familiar with filesystems that don't have parent directories.
Can you name some ?  In theory, these filesystems would have similar
problems implementing LOOKUP of ".." too.

> If this operation is really vital wouldn't it be just as clean
> to us LOOKUP with some special argument.  I would think that
> LOOKUP "" could be used.

Sure, a LOOKUP ".." is probably no more difficult to implement
than LOOKUPP, though I disagree that it's cleaner.  What you've
done is create a reserved name in the filesystem - essentially
forbidding anyone from creating a file called "..".  I think it's
better that NFS v4 not require "special" names.

	Brent

---

From: "G. Allen Morris III" <[email-masked]>
Date: Sun, 26 Sep 1999 09:58:11 -0700

>>>Brent Callaghan said:

I just don't see the advantage of

    PUTROOTFH
    LOOKUP "a" "b" "c"
    GETFH -> fhc
    ...
    PUTFH fhc
    LOOKUPP
    GETFH -> fhb

and

    PUTROOTFH
    LOOKUP "a" "b" "c"
    GETFH -> fhc
    ...
    PUTROOTFH
    LOOKUP "a" "b"
    GETFH -> fhb

However I see a very big disadvantage in the first.  It may return
a filehandle that does _not_ point to directory "/a/b".

Some one may argue that it would be handy for the

    LOOKUP "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l"

case.  But to lookup "f" using LOOKUPP you need:

    PUTFH fhl
    LOOKUPP
    LOOKUPP
    LOOKUPP
    LOOKUPP
    LOOKUPP
    LOOKUPP
    GETFH -> fhf

where if you use "" to signify the parent directory you could use

    PUTFH fhl
	LOOKUP "", "", "", "", "", ""
    GETFH -> fhf

Or the preferred

    PUTROOTFH
	LOOKUP "a", "b", "c", "d", "e", "f"
    GETFH -> fhf

LOOKUP ".." has always been a bad idea, and AFAIK there is only one
major operating system that uses LOOKUP ".." in its client.

I am not saying that the ability to lookup parent directories should
be removed from NFS, what I am saying is that designers should be
strongly discouraged from using it.

 > problems implementing LOOKUP of ".." too.

Yes it would and that is why the whole idea of parent directories
on the server should be discouraged.

 > better that NFS v4 not require "special" names.

It seems that the point of my argument was missed.  My claim it that
the only reason to have any type of lookup parent functionality is
for some strange thin client that does not have any idea of Path
and uses only  READDIR and lookup parent to navigate through the
filesystem.  In this case lookup parent is OK because the client
is not naming the path so the path on the client can't be different
than the path on the server because the client has no path.

Let me state the problems with lookup parent one more time:

1) Not all filesystem have a notion of a parent directory -- or at
   least it is a possibility.

2) There is no way to keep the clients notion of current path and the
   servers notion of the current path the same.  It is possible that
   given a current directory on the client of `/a/b/c' that `ls ..'
   and `ls /a/b' will give different results.  I don't think that 
   most users will find this acceptable!

And the problems with LOOKUPP:

1) Having LOOKUP as a seperate operation is likely to promote its use.

2) It is more functional to use a key word argument to LOOKUP to do a
   lookup parent.  It seems odd that `cd ../../b/c' should take three
   operations when `cd /a/b/c/d/e/f/g' only take one.

SOLUTION:

Remove the LOOKUPP operation and add the text below to the LOOKUP
operation

     Note: previous versions of the protocol assigned special semantics
     to the names "." and "..".  NFS version 4 assigns no special
     semantics to these names.

     A zero length name will be interprepted by the server to represent
	 the parent directory.  If there is no parent directory an ENOENT
	 error must be returned.  Attempting to LOOKUP the parent directory
	 at the root or top of the server's filesystem will aways result in
	 ENOENT being returned.  Receiving an ENOENT does not imply that
	 the current filehandle points to the rootfilehandle.  Client
	 implementors are strongly encouraged not to use this lookup parent
	 feature.

---------------------------------
       G. Allen Morris III

---

From: Gordon Waidhofer <[email-masked]>
Date: Sun, 26 Sep 1999 12:21:26 -0700

You make some interesting observations of LOOKUPP.

>      semantics to these names.

The ".." tradition seems fine to me for LOOKUP. I seriously
doubt anybody is going to break this. Hence
	cd ../../b/c
becomes
	LOOKUP ".." ".." "b" "c"
It's pretty likely that clients and servers would do this anyway,
rather than strictly require LOOKUPP.

>          implementors are strongly encouraged not to use this lookup parent

Zero-length (null) file names have other special meaning
in other protocols. Have you ever wondered why there
is a trailing slash (/) for so many URLs? That's
a null name at the end of that path. And it's special.

If a file name is going to be recognized as parent directory,
then ".." is the answer. No reason to break with 2.5 decades
of history on this one when NT and ISO do the same thing.

So, LOOKUPP merits further thought. Null name for
parent bad idea. ".." is probably going to work anyway.

-- 
==================================================================
  Gordon W Waidhofer                    Traakan Software, Inc.
  [email-masked]                       111 Main St., Suite #5
  650-947-1583  Direct                  Los Altos, CA  94042
  650-947-1580  Main                    http://www.traakan.com
  650-947-1588  Fax

---

From: "G. Allen Morris III" <[email-masked]>
Date: Sun, 26 Sep 1999 15:37:10 -0700

>>>Gordon Waidhofer said:
 [snip]
 > a null name at the end of that path. And it's special.

I am not commited to the use of "" to represent the parent
directory, but I don't think that ".." should be used.
There are filesystems that can have ".." as a filename.
It my be that "" should mean parent directory iff
it is not proceeded by an none zero length lookup
element.  so LOOKUP "", "" would be valid but
LOOKUP "a", "" would be undefined.

 > then ".." is the answer. No reason to break with 2.5 decades

There are 2.5 decades of UNIX history.  My undestanding is that
one of the design goals of NFS v4 is to become less UNIX-centric.

 > parent bad idea. ".." is probably going to work anyway.

   Allen