Subject: Re: seqid in SETCLIENTID

From: Mike Eisler <[email-masked]>
Date: Fri, 7 Jan 2000 10:24:39 -0800 (PST)

I wrote yesterday:

> As a result of some e-mails Dave N. sent me over the
> holiday break, I've re-thought the OPEN confirmation stuff
> a bit. Since a replayed OPEN is only a danger when the
> server has freed the record of the client's clientid, I
						^^^^^^
> think that simply adding a new error code:
> 
> 	NFS4ERR_CLIENTID_NOT_SET
> 
> to the list that can be returned by OPEN will suffice. In
> that case, the client simply sends a SETCLIENTID operation
> and once the clientid set up is done, re-issues the OPEN
> with a seqid of zero.
> 
> This way OPEN is simpler, and we get rid of OPEN_CONFIRM.

The above is completely bogus because I -- once again -- confused
nfs_lockowners with clientids. Dave N. pointed out to me that we
already have an NFS4ERR_STALE_CLIENTID error to deal with the case when
the server reboots and has lost the record of the clientid. My original
OPEN_CONFIRM stuff was intended to allow the server to safely delete
nfs_lockowner's when they fell into disuse. Apologies for the
confusion.

So we can *not* get rid of OPEN_CONFIRM. Revision -03 still needs to be
tweaked to only do the OPEN_CONFIRM step when the server asks for it.
What's missing is a bit in the rflags of OPEN4res to tell the client to
do so.

	-mre