Subject: MOVEs across file systems

From: Jason Crawford <[email-masked]>
Date: Mon, 10 Mar 2003 01:57:58 -0500

BTW... I just had an interesting thought about MOVE's across file systems.
We've been talking about having to do that as a COPY/DELETE.  And on
occasion
we've said that it truly isn't necessary to actually move the resource
implementations as long as they respond at the right URL's.  For the most
part though, that comment has felt a bit academic to me.

Anyway... the thought I just wanted to point out is that if you have a
resource on one file system with multiple bindings to it, and you MOVE
that resource via one of those bindings "to another file system"...
you might actually want to NOT "copy/delete" it since you still also have
several bindings to it from the original file system.  You might
*need* to keep a cross file system binding and not necessarily
move implementations around during MOVE/BIND and other
namespace operations.  And if you're forced to support cross
file system bindings, then perhaps you never really need to take the
COPY/DELETE approach?

Anyway... it's just a stray thought.  :-)

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]
I do not check [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 10 Mar 2003 09:17:12 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Monday, March 10, 2003 7:58 AM
> To: Lisa Dusseault
> Cc: 'WebDAV'
> Subject: MOVEs across file systems
>
>
>
>
>
>
occasion
> Anyway... it's just a stray thought.  :-)

Jason,

that's one of the reasons why I think we'll need REBIND in addition to MOVE,
unless we can get a consensus that MOVE should indeed behave as REBIND.

If you have a system that supports BIND and multiple bindings, but not
across the full namespace (the common example with multiple filesystem
backends, where you don't want to add an additional layer on top of the
basic FS functionality). Let /a and /b represent namespace partitions that
reside in different filesystem partitions. An obvious approach would be just
to mirror what the filesystem backend allows -- a BIND within /a would work,
while a BIND from /a to /b would fail (same for REBIND). However, a client
that doesn't expect this error condition would still be able to MOVE the
resource. In this case, the resource at the target URL of the MOVE request
would *not* be the "same" resource anymore (it would have a different
DAV:resource-id).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Lisa Dusseault" <[email-masked]>
Date: Tue, 11 Mar 2003 08:27:47 -0800

> file system bindings, then perhaps you never really need to take the

A couple counter-reasons: 
 - Quota within the system (top level directories or lower directories
limiting space) this may depend on how the quota is counted - the
system, through its acknowledged limitations, may need to actually move
the resources (not leave them and rebind them) in order to calculate
quota.

 - Disk space outside the system - different parts of the namespace are
frequently literally stored on different disks. Users/Administrators may
move content from one part of the namespace to another *in order* to
transfer to a less-used disk.

Jason, you've clearly got the right instincts for designing a WebDAV
server -- thinking carefully about how to do the best possible job.
It's just a question of can the *protocol* enforce a good job on server
implementors?  Sometimes it can, but sometimes it can't. We wouldn't
want to force atomic DELETEs and have an implementation choose to reject
a great number of large DELETE requests just because it can't guarantee
them all atomic. In the extreme, that would be an even worse tradeoff.

Lisa