Subject: RE: LOCK_RANGE questions

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 8 Aug 2002 20:13:47 -0700

What I meant was that it is up to the client to emulate those
semantics ifit wants those semantics (or is otherwise forced
to provide those semantics).  But NFS-v4 is not going to force
him to provide POSIX semantics.  He MAY return an error
to the user or delete all the user's files, just for spite,
although we probably don't want to say that in the spec.

How about, "it is up to the client implementation (if it is
intended to provide such semantics) ..."?

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, August 07, 2002 5:40 PM
To: [email-masked]
Subject: Re: LOCK_RANGE questions

On Wed, [email-masked] wrote:
> 
> Section 14.2.10 (LOCK) of the latest I-D says that if the server
> returns LOCK_RANGE, "it is up to the client to emulate the required
> operations".  The client is still allowed to return an error to the
> application, rather than emulating the operation, yes?

I read that text as allowing for the client to return an error instead
of attempting the emulation.  No use of the word MUST. :-)

> Section 14.2.11 (LOCKT) says "LOCKT will not return
> NFS4ERR_LOCK_RANGE."  That sounds unnecessarily restrictive on the
> server.  If possible, please change "will not" to "need not".

It seems reasonable that the LOCKT operation should be symmetric to
LOCK.  Maybe Dave Noveck can offer an opinion here since he supplied
the text for these updates.

-- 
Spencer

---

From: [email-masked]
Date: Fri, 09 Aug 2002 16:22:39 -0700

How about

    ...the server will return the error NFS4ERR_LOCK_RANGE.  In that
    case, the client may return an error, or it may emulate the
    required operations, using only LOCK for ranges that do not
    include any bytes already locked by that lockowner and LOCKU of
    locks held by that lockowner (specifying an exactly-matching range
    and type). Similarly, ...

?

mike