Subject: Re: Can you move a locked file?

From: [email-masked]
Date: Wed, 27 Oct 1999 09:38:08 -0400

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 <[email-masked]> on 10/26/99 06:38:31 PM

To:   [email-masked]
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/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 27 Oct 1999 11:16:44 -0400

From: [email-masked]

   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.

OK, as that old campaign slogan went: "Show Me the Beef", or more
precisely, "Show Me the Cost".

First, there is no added cost to a server.  A server can just refuse
the move, if that's what it wants to do.  The benefit to the server is
that it has a degree of freedom it previously lacked.  I described in
an earlier message why this degree of freedom is essential for
supporting versioned collections.

Second, the only client cost of this approach is that a client will
on rare occasion get back a 302 for a locked resource, at which point
it updates its name table and moves on with its business.  It may well
be that this breaks clients in ways I haven't predicted, but I haven't
heard any client implementor make this case.

   I would like to minimize the use of lock tokens
   rather than introducing them as part of namespace management.

Lock tokens already take part in namespace management if they
can "protect" the URL namespace.

   This does not

When collections are versioned, changing a binding is not just an
explicit operation.  It is also the result of a revision rule
evaluation against the versioning metadata (labels, activities,
baselines).  To prevent a binding from being removed, you have to
precede every metadata update with an evaluation of every potentially
affected revision selection rule in every workspace to ensure it does
not violate "URL protection".

I agree with everything Jim says in the preceding paragraph.

Cheers,
Geoff

---

From: Greg Stein <[email-masked]>
Date: Wed, 27 Oct 1999 15:10:17 -0700 (PDT)

On Wed, 27 Oct 1999, Geoffrey M. Clemm wrote:
>...

Then why don't we look at the problems caused by selection rules, rather
than assuming they are fixed and making everything else fit into their
little world?

Why can't we simply constrain the selection rules better, thereby
avoiding the issues that you foresee with locks?

Cheers,
-g

---

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

From: Greg Stein <[email-masked]>

First I should emphasize that these issues only arise with level 3
versioning, which introduces versioned collections.  Level 1 (Core)
and Level 2 (Activity and Configuration) versioning do not provide
namespace versioning, and therefore do not have this problem.

But for many applications, versioning the URL namespace is essential,
so we still need to face this issue for clients that desire support
for namespace versioning.

That is the essence of the fallback proposal I mentioned in an earlier message.
In particular, you would need to:
a) only provide URL protection in the default workspace
b) constrain the selection rules in the default workspace

Restriction (a) is needed because no matter how you restrict the
selection rules, if you allow an arbitrary number of workspaces to
have protected URL's, the cost of pre-computing the effect of even
something simple like a label request will become arbitrarily large.

Restriction (b) is needed because even if you only support URL
protection in a single workspace, some selection rules (such as
configurations and baselines) affect an arbitrary number of
resources, and therefore the effect on the namespace of a baseline
change would require arbitrarily large costs to pre-compute.

Doing away with configurations and multiple workspaces entirely
would eliminate much/most of the value of versioning.

Cheers,
Geoff