W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: MOVEs across file systems

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 10 Mar 2003 20:13:13 +0100
To: "Jason Crawford" <nn683849@smallcue.com>, "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Lisa Dusseault" <lisa@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEHGGLAA.julian.reschke@gmx.de>

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]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
> ...
> > 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
> > reside in different filesystem partitions. An obvious approach would be
> > to mirror what the filesystem backend allows -- a BIND within /a would
> > while a BIND from /a to /b would fail (same for REBIND). However, a
> > that doesn't expect this error condition would still be able to MOVE the
> 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



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

> > 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
> to do better, but if they don't
> support cross-file system bindings and they do a move to another file
> 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.

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


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Monday, 10 March 2003 14:20:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:27 UTC