Re: Can you move a locked file?

   From: jamsden@us.ibm.com

   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
   mean that another principal is unable to create a new binding to the locked
   resource, only that they cannot remove an existing binding.

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".

   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.

I agree with everything Jim says in the preceding paragraph.

Cheers,
Geoff

Received on Wednesday, 27 October 1999 11:16:47 UTC