Subject: RE: CREATE opened file

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 22 Feb 2002 12:24:43 -0800

The spec doesn't say how long you have to keep the verifier,
or even say that when the client does a SETATTR, the server
is allowed to forget the verifier.  But all the servers I know
keep the verifier somewhere in the inode which can be
overwritten when a SETATTR is done.  Are there also servers
that assume that if the client does a WRITE using the returned
file handle from the create, he has proven that he got the
reply and the verifier is not needed any more?  As I understand 
things, this would be OK as well.

It would be nice if the spec laid out exactly how long the
the server is obliged to keep the verifier available for 
comparison.

-----Original Message-----
From: Sergey Klyushin [mailto:[email-masked]]
Sent: Friday, February 22, 2002 2:43 PM
To: 'Noveck, Dave'; [email-masked]
Subject: RE: CREATE opened file

> 
> > 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 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: Spencer Shepler <[email-masked]>
Date: Fri, 22 Feb 2002 17:43:20 -0600

> things, this would be OK as well.

For Solaris/NFSv3, this happens implicitly since the verifier is
stored in the mtime attribute and that changes as result of the WRITE.

I agree that subsequent use of the filehandle returned from CREATE is
sufficient for the server to release the storage of the verifier.

> the server is obliged to keep the verifier available for 

This seems reasonable to clear up any future misunderstanding about an
important feature.

Spencer

-- 
Spencer