W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: Creating a lock-null in a locked collection

From: <ccjason@us.ibm.com>
Date: Tue, 4 Jan 2000 13:48:23 -0500
To: "Eric Sedlar" <esedlar@us.oracle.com>
cc: w3c-dist-auth@w3.org
Message-ID: <8525685C.006741AD.00@D51MTA03.pok.ibm.com>

I think the point is that if the WebDAV locking model is too strange, it
will be hard to reconcile the WebDAV locking mechanism with the other
locking mechanisms.  Introducing new concepts like lock-null's makes it
more difficult and less intuitive to reconcile in this way.
I agree that that was the real point in regard to LNR's.  I think most of
us are willing
to accept that complication if there is also sufficient benefit derived
from it, but based on previous discussions, it doesn't seem folks value
LNR's very much.

Perhaps we should discuss other locking mechanisms in filesystems and
RDBMS's to validate this.
Sounds good.

My understanding is that both Windows & UNIX filesystems lock all of the
names in a directory when the directory is explicitly locked (via
lockf()/flock() or something similar).
If so, that's fortunate because it's what all recent proposals have
I don't think this is the case on Unix though (except by convention)
the locks there appear to be advisory.  I haven't tried any *directory*
locking in Windows but what you suggest sounds likely.

  In Windows filesystems, this
guarantees that the name cannot change since each file can be in only one
On Linux anyone can come along and modify or delete/unlink the (f)locked
resource.  The (f)locks are purely advisory... but are on the resource
itself.  That is, the locks don't prevent operations like
read/write/delete/etc... only other attempts to lock the resource.  And
those attempts to exclusively lock will fail no matter which filename is
used to specify an already locked resource.  -- FWIW, UNIX does  have
shared and exclusive locks.  They don't have read vs. write locks... but
essentially the exclusive lock is a "write" lock and the shared lock is a
"read" lock by convension.  Anyway, my point here is that the lock is on
the resource... and the path is in no sense protected.

On Windows, that's not the case.  Both the resource and the URI path are
locked.. but I haven't seen Windows do multiple bindings in the FS, so
that may change/refine the story here.

Anyone savvy in Window or Unix should feel free to correct me on any of
this.  All of the above is the result of both reading and testing.

Received on Tuesday, 4 January 2000 13:48:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC