From: Spencer Shepler (shepler@eng.sun.com)
Date: 09/20/01-04:16:46 PM Z
Date: Thu, 20 Sep 2001 16:16:46 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Issues list for RFC3010 Message-ID: <20010920161646.A399@dhcp-aus08-191.central.sun.com> On Thu, Sergey Klyushin wrote: > >Issue125: > >Client's REMOVE of an open file still requires the use of a RENAME to a > .nfsXXXX file > >followed by a subsequent REMOVE when the client's applications release > final reference to the open file. > > I think it's still "shaky". Do you mean the same Client sends REMOVE request > or another? > What if another Client sends READDIR and RENAMEs or OPENs .nfsXXXX? The issue was that there was no mention in RFC3010 of the standard NFS implementation practice of renaming a file to .nfsXXXX when an application had the file open at the client. We are referring to the same client. If another client removes the file while another has it open, the application at the client where the file is open will receive an error. This assumes that the server supports the remove of a file that is open (Solaris will support this). > I have proposal to introduce new file/directory attribute: > FATTR4_MARKED_TO_DELETE. > I believe lots of OS support this attribute locally. So how does this work at the server? Is this effective across server restart? (this isn't required since .nfsXXXX would still exist as well but it would be good to know). So the idea is that if the client has the file open and this attribute is returned by the server, the client would go ahead with the REMOVE and when the last NFS OPEN is CLOSEd the file would be removed by the server automatically? What OSes support this feature? Spencer
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:07 AM Z CST