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

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

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

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
Received on Monday, 10 March 2003 14:20:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT