Subject: RE: MOVEs across file systems

From: Jason Crawford <[email-masked]>
Date: Mon, 10 Mar 2003 13:55:29 -0500

> 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.
I don't understand this statement.

> 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).
We might have to accept that for the single binding cases and encourage
them
to do better, but if they don't
support cross-file system bindings and they do a move to another file
system
and the source resource also has additional bindings to it from the
original file
system, then the request MUST be rejected.   If it is not, the server can
not claim
to support the bind spec.

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

---

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Monday, March 10, 2003 7:55 PM
> To: Julian Reschke
> Cc: Lisa Dusseault; 'WebDAV'
> Subject: RE: MOVEs across file systems
>
> ...
>
that
just
work,
client
resource.
> I don't understand this statement.

If you want me to to explain, you'll have to point me to the part you don't
understand :-)

Assume a Unix fs, /a and /b being on different filesystems.

ln /a/a /a/b

will work.

ln /a/a /b/a

won't.

However

mv /a/a /b/a

will work. However the result will not be the "same" resource (it will have
a different inode, and will reside in a different filesystem).

them
system
original file
not claim
> to support the bind spec.

Well, I think that's up to discussion. MOVE suffers from it's RFC2518
definition (COPY then DELETE). REBIND doesn't. I don't see a problem with a
system supporting both (REBIND will fail for some operations, while MOVE
won't).

Julian

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