From: Spencer Shepler (shepler@eng.sun.com)
Date: 09/21/01-03:45:08 PM Z
Date: Fri, 21 Sep 2001 15:45:08 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Issues list for RFC3010 Message-ID: <20010921154508.T398@dhcp-aus08-191.central.sun.com> On Fri, David Robinson wrote: > > I will provide more details. > > 1. The proper attribute name should be FATTR4_DELETE_PENDING > > 2. Meaning of FATTR4_DELETE_PENDING: remove file on the last CLOSE > > 3. This attribute could be set/unset on OPEN operation or on OPENed file by > > SETATTR, providing correct stateid. > > SETATTR with stateid of all 0's or of all 1's can't set this attribute > > 4. REMOVE of OPENed file won't remove file immediately, but will set this > > attribute > > and the file will be deleted on the last CLOSE > > 5. OPEN operation on the file with FATTR4_DELETE_PENDING set will fail with > > ACCESS DENIED error > > The key question is what is the semantics from the server's > perspective from the compound OP <OPEN, REMOVE, READ>? > > One alternative is to simply require the REMOVE of an OPEN > file to fail. Clients can then use the traditional RENAME > trick and REMOVE after CLOSE. > > The second alternative is to allow this sequence. The interesting > question becomes if the REMOVE actually prohibits and further > access of the file through the namespace using the old name? > I think the answer is yes, the server knows the file is open > so it can rename it to a .nfsXXX or move it to a /nfs_deleted_files > directory. The result is that the file can only be accessed > via its file handle, all subsequent LOOKUP or OPEN will fail. > And it is possible to CREATE a new file with the old name. The > server then MUST handle failure in a sane manner, it MUST NOT > delete the file until after the lease interval has expired, but > MAY allow it to last longer if it wants to accept late lease renewals. > > One implication of the second alternative is that file handles MUST > NOT be volitile between the REMOVE and the CLOSE including the > possibility of server reboot. Those servers that cannot meet > this requirement MUST fail the REMOVE and the client may choose > to resort to the old .nfsXXX RENAME trick. > > In either alternative, I don't see the value of the > FATTR4_DELETE_PENDING attribute. It doesn't provide much > useful information to the clients and the servers can > internally track open but removed files. > > My opinion is the second alternative above provides the most > flexibility and is not overly complex for servers that wish > to support it. But still allows simple servers to > implement the first alternative by failing the REMOVE. > (Might need to add a new error code to reflect the response of > "E_thanks_I_would_normally_allow_the_remove_but_sorry_it_is_open". Another last minute thought. What if the server's normal mode of operation is that it will not allow the removal of an OPEN file and therefore needs some special identification that a REMOVE is part of an applications desire to OPEN, REMOVE, READ. Do we want to burden REMOVE with a stateid? Right answer? Too heavy weight? -- - Spencer -
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:09 AM Z CST