- 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
>> 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 much 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 suggested. I don't think this is the case on Unix though (except by convention) because 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 directory. >> 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. Jason.
Received on Tuesday, 4 January 2000 13:48:56 UTC