Subject: [nfsv4] New issue 125: What should LOOKUPP on a named attributes directory return?

From: Benny Halevy <[email-masked]>
Date: Wed, 20 Sep 2006 08:54:49 +0300

I filed the following issue after an informal discussion during last 
interim meeting.

My proposal is that the server SHOULD return the same filehandle of a named
attributes directory when doing LOOKUPP on it. What folks do today?
Does this break any existing applications?

Benny
--

It is not clear from the spec what filehandle should be returned for the 
parent of a named attributes directory.

In an informal discussion held in Ann Arbor during the last interim 
meeting several alternatives were mentioned:
- associated file
- parent directory of the associated file
- the named attributes directory itself

In my opinion, the server should return the filehandle of the named 
attributes directory itself as if it was the root directory of the 
filesystem since it represents a detached hierarchy which cannot be 
reached via LOOKUP or READDIR on any directory (or any other filesystem 
object for this matter, not even the associated file :) in the 
namespace.  Returning either the filehandle of the associated file or of 
its parent directory will surely confuse pwd as a typical implementation 
searches the child in its parent directory's listing by the child's file 
number in order to determine the child name and the named attributes 
directory will never be there.

What current nfsv4 implementations return in this case today?

[for the record, this issue was mentioned already back in 
http://playground.sun.com/pub/nfsv4/webpage/nfsv4-wg-archive-dec-96-jan-03/3358.html, 
point 3]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Jeff A. Smith" <[email-masked]>
Date: Tue, 26 Sep 2006 09:46:53 -0500

> Does this break any existing applications?
The Solaris server returns the base object associated with the attr dir.
Not that it really matters, but our NFS server is returning what
the underlying fs returns for VOP_LOOKUP(..) within an attr dir.
It isn't treated as a special case by the NFS server.  All native
Solaris file systems have this behavior.

To be brutally honest, the current Solaris xattr model/API is quite
"unique".  I suspect it's so different from other xattr APIs that
there are few apps that use it.  But to be fair, I don't have any
data related to user apps broken by this implementation choice.

Certainly if you run an app using an attrdir as it's current working
directory, the app could become confused by doing "cd .." if the base
object isn't a directory.  What broken use case are you wanting to
fix with the new proposal?

Jeff

---

From: Benny Halevy <[email-masked]>
Date: Tue, 26 Sep 2006 18:37:50 +0300

> fix with the new proposal?

Anything that assumes ".." of the named attributes directory is a directory.
E.g. "cd .." as you mentioned, or "pwd".

Benny

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 26 Sep 2006 12:22:48 -0400

> E.g. "cd .." as you mentioned, or "pwd".

If you want chdir("..") to be a no-op on your client for the named
attributes directory, you can do that without help from LOOKUPP--either
remember the fact that you got here by OPENATTR, or check whether the
file type is NF4NAMEDATTR, and do some special handling in that case.

It seems to me that returning the associated object for LOOKUPP in this
case doesn't do any harm, and might provide useful information in some
cases.  And it seems to be what everyone's doing anyway....

--b.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 26 Sep 2006 19:42:45 +0300

> cases.  And it seems to be what everyone's doing anyway....
This works for me.

Benny

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 26 Sep 2006 12:44:55 -0400

> >cases.  And it seems to be what everyone's doing anyway....

The existing text could definitely use clarification, though.  RFC 3530
explicitly mentions the named attribute case, and then doesn't actually
tell you what to do with it....

--b.