RE: 5.5 Write Locks and COPY/MOVE

The main issue in moving a locked resource is ensuring that the destination
is able to keep the lock. Most file system implementations can not move a
locked resource at all and many web servers have namespaces which look
consistent but in fact are implemented across multiple servers. So, for
example, you may go to a web server and see the collections a/b and a/c.
However both collections, while in the same namespace are in fact on
different volumes or even on different servers and as such the web servers
do not have the ability to maintain the lock in a move between these
namespaces. As such requiring that moved resources retain their locks was
considered unacceptably onerous.

As for efficiency, either solution causes the same cost. If we require that
moved resources loose their locks then some systems will have to check all
files in a deep move to see if any are locked. If, on the other hand, we
require that the lock be kept than the majority of implementations will have
to do the exact same search in order to determine if they should fail the
move because a resource is locked. However both arguments are not terribly
germane as moving or copying a hierarchy requires that one transverse the
entire hierarchy, it is the very nature of the operation.

Furthermore the functionality your seek, being able to move a file while
keeping it locked, already exists. One can lock the destination, either at
depth 0 for a single resource or depth infinity for a collection, and then
move the file. The additional benefit of this mechanism is that it will work
even between two servers or volumes which may not be able to exchange lock
information. Please note that the user need not be aware that a second lock
is being taken out. The UI can simply show that the file has been moved and
is still locked, the fact that the lock token has changed should be of no
concern to the user.

It is true, however, that there is a fault here. If one were to lock a
collection and then move a single resource then the lock under which the
single resource now resides would not include the members of the collection.
Thus guarantees made by a single lock across multiple members would be lost.
However providing the functionality to allow for the movement of some
members of a lock while maintaining the other members of the lock has
previously been included in the specification but was removed, by group
consensus, because it was felt that the feature was so complex that there
was no hope that most systems could implement it.

As such the basic ability to move a file and keep it locked is available,
the argument of efficiency does not hold up as the same cost will be paid
regardless of which solution is chosen, and an extension mechanism exists to
allow for these more complicated and expensive locks to be implemented.

It would then appear, in my humble opinion, that the requirement may stay.

			Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Monday, February 09, 1998 6:47 AM
> To:	'WebDAV'
> Subject:	5.5 Write Locks and COPY/MOVE
> 
> section 5.4 states that a write lock must not be moved when a resource is
> moved. This is not the way that DMS systems should behave. There are
> generally different sets of users respnsible for server structure and
> content. The users responsible for the structure may like to move
> resources around. Users who are editing these resources will not be happy
> if their lock gets revoked.
> 
> It also causes problems because it allows a user to release a lock on a
> resource by simply moving a tree structure which contains the resource in
> question - whether their permissions allow this. It is therefore an
> implicit restriction on the permission model of the WebDAV server.
> 
> It is furthermore problematic because it requires a server which has to
> comply with this to scan the tree structure of an entire collection
> hierarchy which is being moved and release all locks on all children. This
> will make efficient move impossible to implement. If this requirement does
> not have-to be met then moving a very deep collection could be done by
> simply moving the parent collection entry from the current parent to the
> future parent.
> 
> This requirement MUST go.

Received on Tuesday, 10 February 1998 17:48:29 UTC