RE: Locks, reservations, copies and moves

Under the heading of "why me?" our systems do it to. Windows 95 can not
move a file with a lock but NT can.

To clarify, however, if you have a file write locked then you may ONLY
move the file if you have the lock. If someone wants a lock that allows
the file to be moved even while locked, please invent a new lock type
and propose it to the group.

That having been said I see a number of options for write locking:

1 - Moving a file with a lock causes the lock to be retained, if the
lock can not be retained then the move fails:

	Upside: Very powerful, clear failure path.

	Downside: All moves on locked files will fail on systems like
Windows 95 AND will most likely always fail when moving a file across
namespaces on a server or across servers. There is also the problem that
the lock token will most likely need to change, especially in cases
where you are moving between servers or namespaces. This isn't too big a
deal as we just need to return the new lock in the response or require
discovery.

2 - Moving a file with a lock causes the system to attempt to try to
retain the lock, but no guarantees:

	Upside: Moves with locks work better on systems like Windows 95
and cross namespace/server moves.

	Downside: We will need to overload the move functionality to
provide for lock discovery, which hurts scalability of the protocol
design or we need to do lock discovery after the move, which is
expensive.

3 - Require that systems supporting moving write locked files:

	Upside: Its a cool feature and clients don't have to write two
sets of code, one for systems that can move locked files and one for
systems that can't.

	Downside: Systems which can't support this feature will not be
able to really implement DAV.

4 - It is illegal to try and move a file with a write lock:

	Upside: Brain dead easy to implement, works everywhere, clients
only have to write one set of code.

	Downside: Robs systems of their ability to move files with locks
if they can handle it.

1 & 2 are the same solution. The reason is that there is no way to tell
the difference between the following scenarios:

Write locked file is successfully moved with lock but then something
happens to cause the lock to go away.

System does not support moving write locked files so it removes the lock
and then moves it.

In other words, stuff happens and your code has to be written to deal
with it.

3 is unacceptable as many systems, for good reasons, will not be able to
support this, especially for moves across namespaces and servers. 4 is
the simplest solution but also robs systems of the ability to move
locked items which could effect atomicity. However I personally feel
this is tripping too far into the domain of transactioning.

As such I propose that we adopt 4, declaring that "DAV is done when
there are no features left to cut." Erring on the side of simplicity for
the first version of a fairly large protocol is probably a good idea.

			Yaron

> -----Original Message-----
> From:	Dylan Barrell [SMTP:dbarrell@opentext.ch]
> Sent:	Wednesday, September 03, 1997 6:23 AM
> To:	Dylan Barrell; 'Del Jensen'; '-=jack=-'; mduerst@ifi.unizh.ch;
> Yaron Goland
> Cc:	w3c-dist-auth@w3.org
> Subject:	RE: Locks, reservations, copies and moves
> 
> Our system - Livelink! Don't get confused betwen OS and document
> management software. the requirements are quite different for the two
> (currently).
> 
> Cheers
> Dylan
> 
> ----------
> From: 	Yaron Goland[SMTP:yarong@microsoft.com]
> Sent: 	Dienstag, 2. September 1997 16:18
> To: 	'-=jack=-'; 'Del Jensen'; mduerst@ifi.unizh.ch; Dylan Barrell
> Cc: 	w3c-dist-auth@w3.org
> Subject: 	RE: Locks, reservations, copies and moves
> 
> Before I go off on a rant, what systems currently allow you to retain
> a
> lock when you move a file?
> 		Yaron
> 
> > -----Original Message-----
> > From:	-=jack=- [SMTP:jack@twaxx.twaxx.com]
> > Sent:	Monday, September 01, 1997 9:43 AM
> > To:	'Del Jensen'; mduerst@ifi.unizh.ch; Yaron Goland; Dylan Barrell
> > Cc:	w3c-dist-auth@w3.org
> > Subject:	Re: Locks, reservations, copies and moves
> > 
> > Th behaviour of removing a lock when moving a resource is bound to
> > result in
> > overwrite conflicts due to locks being inadvertantly lost through
> some
> > structural re-organisation. This will also require that only the
> owner
> > of the
> > lock be able to move the resource which is unnecessarily restrictive
> > in a
> > shared authoring environment where one individual might be
> responsible
> > for
> > content and another for structure.
> > --------
> > I would say that a  lock must be retained when a resource is moved.
> > This
> > is something of a grey area WRT locks and the prevention of
> > overwriting of
> > content.  The main purpose of the lock is to maintain the
> consistency
> > of
> > content when one author out of potentially many is modifying the
> > content.
> > This prevention of other authors modifying the content must be
> > maintained
> > whether or not an administrator decides to move the entire resource
> to
> > some
> > other location.  Note that this isn't dangerous to the content,
> unless
> > the
> > lock is NOT maintained.  I would argue that the lock should simply
> be
> > moved with the resource, which allows administrators the freedom to
> do
> > their jobs without interfering with the maintenance of the
> consistency
> > of
> > content, which is the job the lock does for multiple authors.
> > 
> > -=jack=-
> > 
> > (This text composed by voice)
> > 
> > 
> > -- 
> 
>

Received on Friday, 5 September 1997 18:37:44 UTC