Subject: RE: CREATE opened file

From: "Noveck, Dave" <[email-masked]>
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.

---

From: "Sergey Klyushin" <[email-masked]>
Date: Fri, 22 Feb 2002 14:43:06 -0500

> 
> > Let's consider the case when open_owner has file opened through
previous
> OPEN(OPEN)
> > 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
> Yes.  If the upgrade cannot be granted (access-deny conflict with
another
> owner),
> 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
> 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
> comparing verifiers will allow us to determine whether this is a
repeated
> exclusive

I would also consider this case as "broken client", but protocol doesn't

say anything about checking sequence numbers. If you follow the
protocol,
you have to check verifier only, and if it's the same as stored
verifier,
than you have to succeed. May be we have to clarify it in the
description.

---

From: "Sergey Klyushin" <[email-masked]>
Date: Fri, 22 Feb 2002 15:00:32 -0500

I would like to hear understanding of other implementers 
of open and lock sequence numbers

As I understand the protocol, there are sets of "open owners" and
"lock owners". Any "open owner" could have any subset of "lock owners"
and any "lock owner" could belong to any "open owner"

1. Is open sequence number per "open owner" or 
"open owner + file" (opened by this open owner). 
I would prefer "open owner + file"

2. Is lock sequence numbers is per "lock owner" or
"lock owner + file" or
"open owner + lock owner + file"
I would prefer "open owner + lock owner + file".

Thanks
Sergey

---

From: "Sergey Klyushin" <[email-masked]>
Date: Sat, 23 Feb 2002 14:38:54 -0500

Description of OPEN_DOWNGRADE operation:
=========================================
This operation is used to adjust the access and deny bits for a given
open.  
.......................................
.......................................
The access and deny bits specified in this operation replace the
current ones for the specified open file.  If either the access or
the deny mode specified includes bits not in effect for the open, the
error NFS4ERR_INVAL should be returned.  Since access and deny bits
are subsets of those already granted, it is not possible for this
request to be denied because of conflicting share reservations.
=========================================

Please, correct me if I am wrong:
1. It's possible to "downgrade" from "read+write" access to "read" or
"write" access
2. It's impossible to "downgrade" from "write" access to "read" access
3. It's impossible to "downgrade" from "deny_read" mode to "deny_write"
4. But I hope, it's possible to "downgrade" from any deny mode to
deny_none

Thanks,
Sergey