From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 02/22/02-12:01:37 PM Z
Message-ID: <8C610D86AF6CD4119C9800B0D0499E336A8C7E@red.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: RE: CREATE opened file Date: Fri, 22 Feb 2002 10:01:37 -0800 > Let's consider the case when open_owner has file opened through previous OPEN(OPEN) > or OPEN(CREATE)and sends OPEN(CREATE) request for the same file (THE SAME OPEN_OWNER). If you insist :-) > What should happen? > My understanding of this case: > 1. OPEN(CREATE) with GUARDED flag should fail I agree. > 2. OPEN(CREATE) with UNCHECKED flag should succeed. All attributes are ignored > with exception of file size of zero, as specified in protocol (file will be > truncated to 0). Share_Access and Share_Deny should be processed the same way as > in case of OPEN_UPGRADE. Yes. If the upgrade cannot be granted (access-deny conflict with another owner), then the truncation must not happen. > 3. OPEN(CREATE) with EXCLUSIVE flag. Interesting case. I believe it should succeed > if verifier is the same and Share_Access and Share_Deny should be processed the > same way as in case of OPEN_UPGRADE. I believe the open should fail. You are doing an exclusive create and the file exists. You lose. Maybe I'm misundestanding what you mean when you "should succeed if the verifier is the same", but it sounds like you are saying we should make a special exception if you do two different successive open-create-exclusive requests with the same verifier used for each. I don't see the point of that. If the server received both, for the same lockowner, and they are distinguishable because of different sequence numbers, then he knows that one is not a retransmission of the other, which is the basic purpose of the comparison of verifiers. And if we know that they are not essentially the same request, then the exclusive create can be safely rejected. The client should not be sending two different exclusive-creates with the same verifier. The whole idea of the verifier for exclusive create is that we can write it in the inode (or whatever your own equivalent is) and then be sure that comparing verifiers will allow us to determine whether this is a repeated exclusive create (no matter how much time or how many server reboots have intervened). If the client sends different open requests with the same verifier, he breaks that. > I would like to hear opinion of other implementations.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:49:33 AM Z CST