Subject: Special file names "." and ".." in READDIR response

From: Spencer Shepler <[email-masked]>
Date: Tue, 02 Nov 1999 19:12:01 -0600

There has been an attempt to remove some of the specialness from the
"." and ".." directory names in NFSv4.  However for Unix clients
the "." and ".." entries need to be returned by READDIR and they
need to be the first two entries in the directory.  The reason
for this is that there is software that depends on this ordering.
Unfortunately, the client can not insert the entries on its own
because of the cookie values.  If the client were to insert
the entries on its own it may end up duplicating cookie values
returned by the server and this has potential for confusing the client
and its application.

I would suggest that the protocol make a statement that the
server insert the "." and ".." entries at the beginning of
the READDIR response if they are not natively
supported and describe them as aliases as they were in NFSv3.

This also makes a stronger argument for removing LOOKUPP and
specifying ".." as a special case for LOOKUP as has been 
suggested before.

Spencer

---

From: Neil Brown <[email-masked]>
Date: Wed, 3 Nov 1999 15:11:52 +1100 (EST)

> supported and describe them as aliases as they were in NFSv3.

An alternative would be to reserve a few values in the cookie number
space (0-128?) for client use.  The server would need to get a similar
guarantee from it's underlying filesystem to be able to generate
cookies for "." and ".." anyway.

NeilBrown

---

From: Brent <[email-masked]>
Date: Tue, 02 Nov 1999 23:27:49 -0800

> supported and describe them as aliases as they were in NFSv3.

It's great that the protocol, thusfar, has avoided reserving
special names.  I'd be disappointed if we give in so easily
to returning "." and ".." to the readdir result on the pretext
that the client might get confused if they're not there.

I like Neil's suggestion to reserve values.  Cookie 0 is already
reserved.
Why not also reserve cookies 1 and 2.  Then the server
can construct valid cookies just by adding 2 to the cookie
value.  I'm sure the server can manage with those two cookie values
missing from its cookie space.

	Brent

---

From: Jude Giampaolo <[email-masked]>
Date: Wed, 3 Nov 1999 06:45:14 -0400

>missing from its cookie space.

I have to agree with this. When I wrote a v2 server, special casing '.' and
'..' was a pain. Having special cookie values would have gone a long way in
solving the problem.

--
Jude Giampaolo
[email-masked]
[email-masked]

---

From: Erez Zadok <[email-masked]>
Date: Wed, 3 Nov 1999 10:39:09 -0500 (EST)

I'm new to this wg, and have not had time to read the whole spec yet.  (It's
a bit long. :-) Apologies if these are novice questions.

The current spec does not mention if the readdir cookies returned by the
server have any order.  Are they monotonically increasing, decreasing, or
should have no implied order.  The spec does mention this on page 133:

     "The cookie is similar in concept to a READ offset but should not be
     interpreted as such by the client."

This would imply that it is a monotonically increasing value, as read
offsets are.  I think the spec should decide if these cookies have any
implied order, and be more specific about it.

The Linux 2.3 NFS client, for example, implicitly assumes that cookies are
monotonically increasing.  The Amd automounter, which I maintain, could
sometimes produce cookies of decreasing numeric values (but unique of
course).  This was to support directory browsing of automounted mount
points.  I've had problems with Amd on Linux 2.3 hosts because of that;
parts of directories were not being interpreted by the client side and thus
became invisible to directory listing.  I've spoken to the linux person who
wrote that code and he said that he knew that he was (somewhat) breaking the
(V.2) spec, and that the problem will be fixed in linux 2.4.  I "fixed" the
problem by ensuring that Amd returns monotonically increasing cookies.

Nevertheless, I think it would be useful to add a statement to the V4 spec
clarifying this issue.  You say that clients should not assume that cookies
represent actual offsets, but should clients assume (the weaker statement)
that cookies are monotonically increasing?  I think not.

---
Erez Zadok.
Columbia University Department of Computer Science.
EMail: [email-masked]           Web: http://www.cs.columbia.edu/~ezk

---

From: Erez Zadok <[email-masked]>
Date: Wed, 3 Nov 1999 10:26:13 -0500 (EST)

> '..' was a pain. Having special cookie values would have gone a long way in

I also agree that special casing them would be helpful.  I also would have
found it useful when I added the "readdir" support to Amd (the automounter),
so that people can browse automounted directories.

However, if these cookies are known to be 1+ or 2+ a given value, there's a
danger that clients might assume that.  So maybe a statement clarifying this
should be made?

Erez Zadok.