RE: DELETE leaving a lock-null resource; was LOCK Scenarios

> Using the updated proposal where a process gets back a 302 when it
> tries to access a locked resource that has moved, word will have to
> update its path to the document the next time it accesses it for read
> or write.  When it does so, the user will know to look
> at the new place in a different process.
> 
> Also note that a user is already used to some difference 
> between what is
> seen in the process that has the lock and another process 
> that does not.
> In particular, any changes that have not yet been saved will 
> only appear
> in the process with the lock.

How long do you expect the original resource to remember the forwarding
information? So if you move foo/bar to foo/baz and someone else creates a
new resource at foo/bar then the forwarding from foo/bar to foo/baz will be
destroyed. These are file systems, they don't have long memories.

Also, how do you think the UI in Hiro's word processor is going to tell him
about the name change? "Dear Hiro, someone decided to move your file for
you, it now lives at the following name." I can't ship that product, my
users would revolt.

> Probably somebody who had a good reason do so (perhaps fixing a bad
> copyright statement in her document).  In either case, there is no
> lost update problem, since she has no pending updates to the document
> (except for those only in her head, which we can't take responsibility
> for :-).

The only problem is that her document has mysteriously disappeared, even
though she locked it. Admittedly this can happen anyway if the admin
overrides her lock but that is a very rare circumstance and enough of a
disaster that the admin would be expected to send e-mail out to those
affected. The same would not be true here. If Joe comes along and moves the
entire directory and isn't aware that Irit had a locked file he would never
know he should tell Irit. So when Irit comes back her file is gone and she
has no idea what has happened. Even if Joe knew, it wouldn't be sufficient.
Irit wants her stuff staying where it is, that is why she took out the lock.
You seem to believe that locks are just there to protect content. That
simply isn't true. Locks are there to control the name for it is the name
which gives access to everything. By controlling the name you control where
the name can be moved as well as who can access the content pointed to by
the name. Locks are more about names then they are about content.

> 
> My generic response to this situation: locks are great for preventing
> lost updates.  You LOCK,GET,edit,PUT,UNLOCK.  The faster you 
> get in and
> out with your lock, the better.  If you want to leave the world locked
> up so that your job is easier, you're ignoring the needs of all the
> other people that need to get their jobs done.
> 

In our experience the over whelming majority of documents are one user at a
time. That is, one user edits and then hands over control to another user.
Locks prevent control from being transferred prematurely. They also prevent
unwanted changes to shared namespaces. While documents are often single
user, namespaces are often shared. 

Widespread use of collaborative editing is only now starting and is in its
most infant stages. For a very long time most documents will be used by one
and only one person and suffer the problems described in the previous
paragraph. In fact, according to our studies, the #1 mechanism used to
collaborate on a document is e-mail. Copies get sent around and someone acts
as a redactor.

> With the speed of development and deployment being forced by 
> "internet time",
> I believe the days of locking up the world to get long-term 
> stability are over.
> 

I don't know what is in the future, only what is in the present. WebDAV has
to be able to do what we can already do today before it can move into
uncharted territory. The locking proposal prevents scenarios that work today
and thus prevents WebDAV's adoption by file system based programs that exist
today.

> Cheers,
> Geoff
> 

The bottom line is the question of the relationship of names to locks. In
the file system world a name is the single most powerful piece of
information one has. The name is used to retrieve, to change, to control.
One of locking's most critical tasks is to provide for control over that
name. That is why WebDAV causes names to be locked along with content. This
wasn't an accident, it was a conscious choice based on experience shipping
editing systems that work against file systems.

Until the whole world moves over to powerful versioning systems we will have
to deal with file systems and in file systems, file names are king. Thus my
users MUST be able to pin down a name, own it and totally control it.

So long as there are file systems locks MUST control names.

			Yaron

Received on Saturday, 23 October 1999 17:45:42 UTC