Subject: Can you move a locked file?

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Sun, 24 Oct 1999 09:49:30 -0700

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:[email-masked]]
> Sent: Saturday, October 23, 1999 5:11 PM
> To: [email-masked]
> Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios
> 
> 
>    From: "Yaron Goland (Exchange)" <[email-masked]>
> 
>    > 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
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sun, 24 Oct 1999 14:18:47 -0400

Then they should just make sure to buy a server that blocks MOVE's of
locked files (which I agree a server should be able to do).

Which means they probably will instead chose a server that does lock
tracking and returns 302's.

So they buy different servers, but clients and servers can use the
same protocol ... and everybody is as happy as one can reasonably expect.

   can't)

I feel compelled to point out that $200 times 10 million users equals
2 billion dollars (:-).  Also that the current complexity of that $200
OS product makes lock monitors and auto-email an unmeasurably small
increase in complexity.  But then again, probably the last thing it
needs is even an unmeasurably small increase in complexity (:-).

   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.

Fair enough.  So we make sure that the protocol allows their server to refuse
to do the moves.

Bad choice.

What about choice 3:

   Choice 3 - The protocol allows a server to either refuse the move
   (returning "locked" status) or to promise to track the move and return
   302's as appropriate.  No problem for the clients, since they have to
   deal with 302's anyway, and no problem for the servers, since they can
   do what they believe is the right thing for their users.  Then we
   let the market decide which server was right ... and all the while,
   we have one common protocol to interoperate with.

Cheers,
Geoff

---

From: John Stracke <[email-masked]>
Date: Tue, 26 Oct 1999 18:02:38 -0400

"Yaron Goland (Exchange)" wrote:

> to manipulate their "private data worlds" in anyway.

Uh...isn't that what access control is for?

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Please do not adjust your mind--reality is   |
[email-masked]|malfunctioning.                              |
\==============================================================/

---

From: Greg Stein <[email-masked]>
Date: Tue, 26 Oct 1999 15:38:31 -0700 (PDT)

> Uh...isn't that what access control is for?

I don't think so. Access control is long-term, locks are
shorter/transitory.

I totally agree with Yaron here: if I'm editing a document (with a lock),
then it sure as hell better not move on me. That is just annoying and
wrong.

This whole business about the server retaining redirects after a move of a
locked resource seems really and arbitrarily complex. Why support
something like that? Just say a server MUST refuse a move of a locked
resource rather than "well, it might or it might not, but you really won't
know unless you try."

And if this nonsense does go thru as a "consensus change" to the move/lock
behavior, then the default should be to refuse the move. There was a
suggestion that an app should set a flag to state that it can't support
locked resources that may move -- that's backwards since the current
behavior is "I lock it and it stays there until I unlock it." In other
words, an app should say "I can support you [the server] moving this
locked resource on me and sending me a 301 response."
(I still don't like it though because of the additional complexity on the
client, which people seem to be ignoring, much to Yaron's dismay; who on
this list is actually writing client software/tools/apps?)

Personally, I'll refuse the darn move. I'm not going to start recording
all these redirects on the server.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 27 Oct 1999 00:28:52 -0400

From: Greg Stein <[email-masked]>

It's also annoying and wrong for a resource that is on my favorites
list to be moved away and have me get a 302 back.  Why not just leave
the darn thing where it is?  Well, there are sometimes good reasons to
move it.  And these reasons also apply, even if someone currently has
a write lock out on some leaf resource.  Luckily, it's quite easy to
cope with a 302, so life goes on.

If the proposal was that a server MUST allow the move and MUST
provide 302's, I could see the server writers complaining.  But that's
not the case.  A server is free to block the move, if that's what it
thinks best serves its customers (or is the easiest to implement).

I agree that getting a 302 on access to a locked resource would be
new behavior, but I have heard no arguments (convincing or otherwise :-)
as to how a 302 would be hard for a client to deal with.

What causes something to be renamed by a versioning server is not just
a MOVE operation, but rather any change to any metadata that affects
the revision selection for a versioned collection.  Unless it
re-computes all revision selection rules for all versioned collections
before *any* requested metadata change (i.e. moving a label, changing
the member of a configuration), it won't know whether or not the name
of a locked resource will change.

So although a versioning server can always tell you where your
versioned resource is, it is computationally infeasible for it to
detect whether the name of a locked resource is affected by a change.
I'm just looking for a compromise that gives us interoperability
between down-level clients and versioning servers.

I personally would not favor any flag that splits the locking behavior
into two different flavors.  Since I can't imagine clients putting in
alternative code paths for these different flavors of locks, this just
guarantees non-interoperability, as each flavor of server fails a
client's request to provide the other flavor of lock.

We should just pick one interoperable semantics.  I'd just like us
to pick a semantics that is implementable by both versioning and
non-versioning servers.

Every versioning server implementor on this mailing list that I know of is
also a client implementor.  This is also true for all the document management
system server implementors that I know of.

I'd be against any protocol that required you to do otherwise.  I'd
just like to see us produce a protocol that is compatible with
versioning (after all, this is Distributed Authoring and Versioning :-).

Cheers,
Geoff

---

From: [email-masked] (WJCarpenter)
Date: Wed, 27 Oct 1999 14:37:43 -0700

gmc> I personally would not favor any flag that splits the locking
gmc> behavior into two different flavors.  Since I can't imagine
gmc> clients putting in alternative code paths for these different
gmc> flavors of locks, this just guarantees non-interoperability, as
gmc> each flavor of server fails a client's request to provide the
gmc> other flavor of lock.

Well, uh, sheesh, I almost regret having to point this out, but the
current LOCK method already describes two flavors of locking, and it
seems to me that that overloading is what is causing the current
disagreement and discussion.

LOCKing a resource and LOCKing a namespace are different animals,
whether you use the same verb or not.  Having the method overloaded
gives the opportunity for (1) implementation errors, and (2) wishing
it weren't so.
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3