Subject: Directory cookies (a brief summary)

From: Spencer Shepler <[email-masked]>
Date: Wed, 7 Feb 2001 02:17:24 -0600

A lot of discussion about directory cookies.  We have a proposal on
the table to change the nfs_cookie4 definition from an uint64 to
an opaque <>.

The main issue is with the NFS client's ability to interact
appropriately with the APIs on the client.  There has been a
suggestion that the client may be able to implement a mechanism that
would provide appropriate behavior for the telldir()/lseek()/seekdir()
APIs but this claim seems a little weak at the moment.

So at this point, I don't see a consensus as to changing the directory
cookie unless we have some implementation experience with an
appropriate solution for the client.

-- 

- Spencer -

---

From: Carl Beame <[email-masked]>
Date: 10 Feb 2001 15:59:43 +0000

I have been skiing for the last week and came back to this pile of
Readdir cookie issues. Having only skimmed the messages, I thought
that I could add my two cents (shillings) to this discussion. It may
NOT be useful but it just might.

Our NT NFS Server implements readdir in the following way.

The cookie returned is the fileid of the file. There is a cache of
"open" readdirs (which are open FindFirstFile() calls) if the
filehandle of the directory matches and the cookie matches the stored
fileid, we just call FindNextFile() with the stored Handle. If no
cached readdir is present we start a new FileFirstFile() searching for
the fileid presented in the requested cookie.

This WILL fail only if there is no cached readdir present AND the
file which is the last fileid (cookie sent) has been deleted. 

My question is why pass filenames as cookies when you could pass
fileids and translate them back to names on the server?

- Carl