From: Spencer Shepler (shepler@eng.sun.com)
Date: 09/21/01-04:43:31 PM Z
Date: Fri, 21 Sep 2001 16:43:31 -0500 From: Spencer Shepler <shepler@eng.sun.com> Subject: Re: Issues list for RFC3010 Message-ID: <20010921164331.V398@dhcp-aus08-191.central.sun.com> On Fri, David Robinson wrote: > > 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? > > Aghh, no... we have too much exposed state as it is... :-) > The problem only occurs when the client and server have different > semantics for the removal of an open file. If the > client APIs prohibit it the server will not see an OPEN-REMOVE > unless the client is buggy. If the client allows it but the server > prohibits it, the server sends back an error and the client > if it wishes to protect the application must try a different > trick like the .nfsXXX RENAME. And lastly if both allow it the > server must maintain internal state that survives a reboot > for error recovery. > > What I was trying to do here was come up with a semantic that > doesn't require the server to expose any state to the client. > Sergey's solution looked workable but it forced the client > to track more state. Well technically if the client needs > to perform the RENAME .nfsXXX trick that is state that it > needs to track, but that was solved 15 years ago and already > exists in all OSes that care. The client maintaining the > state that a file is OPEN is sufficient. But you didn't address the issue when the server can support it but only in cases that it knows that it is what the client wants. Suppose we have a server (say the win2k server) that will disallow REMOVE of an OPEN file in the general case. However, it has the underlying capability to allow the client the OPEN, REMOVE, READ sequence. Your proposal doesn't allow the client a method of determining that capability. Maybe Sergey can let us know if this is what his server might do? -- - Spencer -
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:09 AM Z CST