Subject: Re: file_id

From: Jim Rees <[email-masked]>
Date: Mon, 02 Dec 2002 05:20:54 -0500

Hashing the filehandle doesn't work either.  Although they are guaranteed
unique, they are not guaranteed not to change.  Lack of a true unique
identifier is one of the more strange and difficult aspects of nfsv4.

---

From: Neil Brown <[email-masked]>
Date: Mon, 2 Dec 2002 21:46:00 +1100

> identifier is one of the more strange and difficult aspects of nfsv4.

To be fair:

 Not having a stable/unique/64-bit identifier is one of the more
 difficult aspects of some filesystem implementations that NFSv4
 wishes to be able to talk to.
or
 requiring a stable/unique/32-bit identifier is one of the more
 difficult aspected of the POSIX interface that NFSv4 wishes to be
 able to support. (Well, some POSIX systems want 32bit, some are happy
 with 64bit).

i.e. it isn't NFSv4's fault.  It is just the bearer of bad news.

I would kind-a like NFSv4 to allow the server to tell the client how
many bits (the minimum) that are guaranteed to be unique.
As it is, a 32bit client cannot get a 32bit file_id that is certain to
be unique, even if the server provides one.  This failure of
communication is a flaw in the protocol.

NeilBrown

---

From: David Robinson <[email-masked]>
Date: Mon, 02 Dec 2002 10:31:13 -0600

> identifier is one of the more strange and difficult aspects of nfsv4.

I did say "Not perfect but probably good enough." :-)

If a server that has volitile file handles, you are correct that
this may fail, but realistically it will only fail if the value
of the file handle changes during the lifetime of one of the few
commands that look at st_ino (e.g., cp, find).

I still think it is a "good enough" workaround. :-)

	-David