Subject: RE: [nfsv4] hi

From: "Halevy, Benny" <[email-masked]>
Date: Wed, 28 Jan 2004 13:13:46 -0500

Dave Noveck wrote:
>Is it reading too much into this, 
>to think that it implies that if the numlinks field of the previous 
>attributes has a value greater than one, the client may indeed rely 
>on referring to the object via a filehandle?   

What do you mean by "rely on"?
Does the client have any alternative but to use the filehandle?
Even when the client observes a link count of 2 or more it may
change asynchronously and without notification.

I agree with the spec that applications that care about this
need to proactively protect open files from removal.

The mechanism described in the spec for doing this is:

   The usual mechanism used is to RENAME the file from its
   old name to a new hidden name.

Linking the file to hidden name at open time rather than renaming it
and then unlinking the hidden name on close may be a better implementation
choice if the original name needs to be accessible while the file is opened.
Just my $0.02...

Benny

>-----Original Message-----
>From: Noveck, Dave [mailto:[email-masked]]
>Sent: Wednesday, January 28, 2004 12:39 PM
>To: Halevy, Benny; namit jain; [email-masked]
>Subject: RE: [nfsv4] hi
>
>
>Benny Halevy wrote:
>> The semantics you are asking about are file system specific.
>
>The spec generally treats such questions as within the purview
>of the server's file system semantics.  However, it is interesting
>to note that the section of the spec you quote:
>
>   However, if the numlinks field in the previous attributes of the 
>   object had the value 1, the client should not rely on referring 
>   to the object via a filehandle.
>
>can be read as implying otherwise.  Is it reading too much into this, 
>to think that it implies that if the numlinks field of the previous 
>attributes has a value greater than one, the client may indeed rely 
>on referring to the object via a filehandle?   
>
>
>
>-----Original Message-----
>From: Halevy, Benny [mailto:[email-masked]]
>Sent: Tuesday, January 27, 2004 8:30 PM
>To: 'namit jain'; [email-masked]
>Subject: RE: [nfsv4] hi
>
>
>The semantics you are asking about are file system specific.
>
>Unix file systems typically allow you to access a file after
>the name you used to open it was deleted.
>
>An interesting point though is what happens when *all* links
>to that file are removed.  Most Unix/Posix implementations
>(on the server side) will allow access to the file until last close
>and only then they will obliterate the file.
>
>NFSv4 does not require that semantic. Meaning that opening a file
>will not guarantee you that the file will be accessible
>if all of its names were deleted (possibly by other clients).
>
>See RFC3530 section 14.2.26.  Operation 28: REMOVE (Page 195)
>[snip]
>   If the entry in the directory was the last reference to the
>   corresponding filesystem object, the object may be destroyed.
>[snip]
>   The concept of last reference is server specific.  However, if the
>   numlinks field in the previous attributes of the object had 
>the value
>   1, the client should not rely on referring to the object via a
>   filehandle.  Likewise, the client should not rely on the resources
>   (disk space, directory entry, and so on) formerly 
>associated with the
>   object becoming immediately available.  Thus, if a client 
>needs to be
>   able to continue to access a file after using REMOVE to remove it,
>   the client should take steps to make sure that the file 
>will still be
>   accessible.  The usual mechanism used is to RENAME the file from its
>   old name to a new hidden name.
>
>   If the server finds that the file is still open when the REMOVE
>   arrives:
>
>   o  The server SHOULD NOT delete the file's directory entry if the
>      file was opened with OPEN4_SHARE_DENY_WRITE or
>      OPEN4_SHARE_DENY_BOTH.
>
>   o  If the file was not opened with OPEN4_SHARE_DENY_WRITE or
>      OPEN4_SHARE_DENY_BOTH, the server SHOULD delete the file's
>      directory entry.  However, until last CLOSE of the file, the
>      server MAY continue to allow access to the file via its
>      filehandle.
>
>- Benny
>
>>-----Original Message-----
>>From: namit jain [mailto:[email-masked]]
>>Sent: Monday, January 26, 2004 3:21 PM
>>To: [email-masked]
>>Subject: [nfsv4] hi
>>
>>
>>
>>
>>Does nfs v4 specify the read behavior of deleted 
>>files ? Say, /a/b/c.txt and /a/d/e.txt are links to
>>the same file:
>>
>>If the user does the following operations::
>>
>>cd /a/b
>>LOOKUP (c.txt) --> return filehandle FH1
>>READ (FH1)
>>
>>The file /a/b/c.txt is deleted (by the same or a 
>>different request)
>>
>>READ (FH1) --> is is OK if the READ succeeds since
>>/a/d/e.txt might still exist.
>>
>>
>>
>>Thanks,
>>-namit
>>
>>__________________________________
>>Do you Yahoo!?
>>Yahoo! SiteBuilder - Free web site building tool. Try it!
>>http://webhosting.yahoo.com/ps/sb/
>>
>>_______________________________________________
>>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