From: Benny Halevy (benny_halevy@yahoo.com)
Date: 08/04/02-09:30:58 PM Z
Message-ID: <20020805023058.34297.qmail@web14102.mail.yahoo.com> Date: Sun, 4 Aug 2002 19:30:58 -0700 (PDT) From: Benny Halevy <benny_halevy@yahoo.com> Subject: Re: Issue 77 (was "draft-02-00 posted") I would vote for "the server SHOULD grant the read". It might be impossible for some servers to provide bypass around exclusive locks - e.g. NFSv4 gateways which export a file system which support only strict locking. This could also allow finer semantics in the future like having a "strict_byte_range_locks" attribute per file/file system or allow-deny modes per lock -allow=READ, deny=WRITE for share locks (READ_LT); allow=WRITE|BOTH, deny=BOTH for exclusive locks (WRITE_LT); allow=WRITE|BOTH, deny=WRITE for weak write locks. That way the semantics can be determined in an application specific manner to support both databases which may require strict exclusive locks and "regular" files which could have looser semantics. - Benny --- mike.kupfer@sun.com wrote: > Issue 77 is > > Clarification in Section 8.1.4. It says > > "A stateid of all bits 1 (one) allows READ > operations to bypass > record locking checks at the server." > > It needs to state whether the server MAY grant the > read, versus the > server MUST grant the read. > > The indicated resolution is > > Resolved by previous re-writes of the special > stateid discussion > > So I reviewed the special stateid discussion in > Section 8.1.4. My > reading is that the server MUST grant the read. > Does anyone disagree? > > mike __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:08 AM Z CST