Subject: RE: [nfsv4] hi

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 28 Jan 2004 09:38:40 -0800

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