Can you move a locked file?

While I understand your justifiable fear that the access linearization
caused by locks will hinder collaboration you must understand that the
reason my users use locks is exactly that - they want to PROHIBIT
collaboration.

My user's explicit goal is to prevent anyone, anywhere from have any ability
to manipulate their "private data worlds" in anyway. This begins with the
formation of the namespace and continues to the manipulation of content.

For my users WebDAV is a great way to access a large number of "private data
worlds."

For your users, WebDAV is a great way to powerfully leverage the
collaborative features of the web.

Our two user's needs are in direct conflict.

You have proposed two mitigating technologies, lock monitors and auto-email
notifications. Even if I could include those in a $200 OS product (which I
can't) I would not do so anyway because my users do not want to have to deal
with the ramifications of these technologies. My users do not want to get an
e-mail telling them their files have moved. They just want their files to
stay where they were put.

Given the contradictory needs of our user bases I see two choices.

Choice 1 - We agree to disagree. Deciding the problem is irresolvable we
create two types of locks in WebDAV. This, of course, destroys any hope for
interoperability and puts blocks in the road of my users as they "grow" from
their current "private data world" model to a more open "collaborative world
model."

Choice 2 - We agree that locks, as unfortunate as it may be, must lock the
namespace and accept this limitation as the cost of bringing the widest
number of users into WebDAV.

				Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Saturday, October 23, 1999 5:11 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios
> 
> 
>    From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>
> 
>    > 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.
> 
>    How long do you expect the original resource to remember 
> the forwarding
>    information?
> 
> In an implementation, it often isn't the resource that is remembering
> the forwarding information, but rather some locking 
> authority.  This is
> true for many WebDAV implementations (although certainly not all).
> The locking authority must maintain any forwarding information
> for the lifetime of the lock.
> 
>    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.
> 
> If an implementation cannot maintain forwarding information, 
> then it must
> fail the move (with a "locked" status).
> 
>    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.
> 
> If Hiro's word processor is using HTTP (the premise of 
> WebDAV), it had better
> be prepared to handle a 302.
> 
>    > 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.
> 
> The lock is there, and Joe could easily notify all the lock 
> holders (assuming
> the locks hold principal information, as is recommended).  In 
> fact, if he
> had a good client, it could largely automate the notification process.
> 
>    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.
> 
> And I want to put red lights on all cross-roads of all the 
> intersections
> on my way to work (:-).  But I'm not allowed to do that 
> because it interferes
> with everybody else's commute.  Just a silly analogy, but not too
> far off the mark, I believe.
> 
>    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.
> 
> I think we agree that locks are there to prevent the lost update
> problem (i.e. protecting content).  It is an interesting question as
> to whether they are appropriate for preventing other problems, and if
> so, how they are best used to do so.  I believe that locks are useful
> for keeping a handle on where a locked resource is located, but that a
> server should be able to allow the move and return a 302, if it wants
> to maximize parallel work.  A server can also just fail a moves if it
> cannot track the movement of a locked resource.
> 
>    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. 
> 
> Yes, it is the shared nature of namespaces that causes me to resist
> requiring anything like a "namespace lock".  To say that a server can
> do such a lock if that's the best it can to, then that's fine.  But
> to say that all servers must act that way leaves out a useful
> alternative, namely, using 302's to let a client know the new location
> of their locked resource.  Since a web client needs to know
> how to deal with 302's anyway, I believe there is little or no
> additional cost to clients.
> 
> Cheers,
> Geoff
>

Received on Sunday, 24 October 1999 12:49:46 UTC