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

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 5 Oct 2006 09:55:07 -0400

Wasn't the original request for more specificity on what the 
server should return when a LOOKUPP is done on a named
attribute directory?  This talks about what the client should
do to deal with servers that happen to return the filehandle
of the associated file, but it doesn't say what LOOKUPP 
should or SHOULD do.  It just says what they may do.

There's nothing wrong the paragraph, but it doesn't seem to
address Issue 125.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Thursday, October 05, 2006 8:54 AM
To: Benny Halevy; J. Bruce Fields; Jeff A. Smith; Khan, Saadia
Cc: [email-masked]
Subject: Re: [nfsv4] New issue 125: What should LOOKUPP on a named
attributesdirectory return?

I propose to add the following two paragraphs to sections
10.5.  (Additional Client-side Considerations) and 16.14.4.
(Operation 16: LOOKUPP / DESCRIPTION), respectively.

Benny

--- draft-ietf-nfsv4-minorversion1-07.txt       2006-10-05 
14:07:37.000000000 +0200
+++ draft-ietf-nfsv4-minorversion1-07-bhalevy.txt       2006-10-05 
14:27:18.000000000 +0200
@@ -9450,22 +9450,30 @@

    One important issue is upward navigation from the root of a server-
    side file system to its parent (specified as ".." in UNIX).  The
    client needs to determine when it hits an fsid root going up the
    filetree.  When at such a point, and needs to ascend to the parent,
    it must do so locally instead of sending a LOOKUPP call to the
    server.  The LOOKUPP would normally return the ancestor of the
target
    file system on the target server, which may not be part of the space
    that the client mounted.

-
-
+   A related issue is upward navigation from named attribute
directories.
+   The named attribute directories are essentially detached from
+   the namespace and this property should be safely represented in the
+   client operating environment.  LOOKUPP on a named attribute
directory
+   may return the filehandle of the associated file and conveying this
+   to applications might be unsafe as many applications expect the
parent
+   of a directory to be a directory by itself.  Therefore the client
may
+   want to hide the parent of named attribute directories (represented
+   as ".." in UNIX) or represent the named attribute directory as its
+   own parent (as typically done for the filesystem root directory in
UNIX)

 Shepler, et al.         Expires February 2, 2007              [Page
169]

 Internet-Draft            NFSv4 Minor Version 1              August
2006

    Another issue concerns refresh of referral locations.  When
referrals
    are used extensively, they may change as server configurations
    change.  It is expected that clients will cache information related
    to traversing referrals so that future client side requests are
@@ -17443,20 +17451,25 @@
    directory, the error NFS4ERR_NOTDIR is returned.

    If the requester's security flavor does not match that configured
for
    the parent directory, then the server SHOULD return NFS4ERR_WRONGSEC
    (a future minor revision of NFSv4 may upgrade this to MUST) in the
    LOOKUPP response.  However, if the server does so, it MUST support
    the new SECINFO_NO_NAME operation, so that the client can gracefully
    determine the correct security flavor.  See the discussion of the
    SECINFO_NO_NAME operation for a description.

+   If the current filehandle is a named attribute directory that is
+   associated with a filesystem object via OPENATTR (i.e. not a
+   sub-directory of a named attribute directory) LOOKUPP SHOULD return
+   the filehandle of the associated filesystem object.
+
 16.14.5.  IMPLEMENTATION

Benny Halevy wrote:
> J. Bruce Fields wrote:
>> On Tue, Sep 26, 2006 at 06:37:50PM +0300, Benny Halevy wrote:
>>  
>>>> 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?
>>>>       
>>> Anything that assumes ".." of the named attributes directory is a 
>>> directory.
>>> 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.
>>   
> This works for me.
>
> Benny
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

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

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 5 Oct 2006 10:13:28 -0400

--b.