Re: Can you move a locked file?

I have to agree with Greg and Yaron. I too think that locking a resource
should prevent it from being moved except by the owner of the lock. It
doesn't seem like the flexibility for allowing locked resources to be moved
by others justifies the complexity it adds to the protocol semantics and
server implementations. I would like to minimize the use of lock tokens
rather than introducing them as part of namespace management. This does not
mean that another principal is unable to create a new binding to the locked
resource, only that they cannot remove an existing binding.

However, I don't think this completely resolves the locking problem. The
reason this came up was with respect to MOVE retaining locks. The current
spec says locks are lost on move, even if the owner of the lock is doing
the move. MOVE could be either a rename or copy/delete depending on how the
server has to implement it. It is my understanding that the advanced
collections specification has specified the semantics of MOVE as rename,
and if clients want to do a COPY/DELETE,  they can do that and hide it in
their UI. This makes MOVE a kind of rebind that does not disturb other
bindings, or actually require the physical resource to move. (Perhaps it
should be called RENAME then). In this case, it doesn't make sense for the
locks to be lost. Only the lock owner can do the MOVE, and the locks should
be retained. There is no need to change COPY/DELETE semantics with respect
to locks, only this new, more specific definition of MOVE.






Greg Stein <gstein@lyra.org> on 10/26/99 06:38:31 PM

To:   w3c-dist-auth@w3.org
cc:

Subject:  Re: Can you move a locked file?



On Tue, 26 Oct 1999, John Stracke wrote:
> "Yaron Goland (Exchange)" wrote:
>
> > My user's explicit goal is to prevent anyone, anywhere from have any
ability
> > to manipulate their "private data worlds" in anyway.
>
> 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/

Received on Wednesday, 27 October 1999 09:42:51 UTC