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

RE: MOVEs across file systems

From: Jason Crawford <nn683849@smallcue.com>
Date: Mon, 10 Mar 2003 15:15:34 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: "Julian Reschke" <julian.reschke@gmx.de>, "Lisa Dusseault" <lisa@xythos.com>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <OF2657A6F4.8DED614D-ON85256CE5.006D227E@us.ibm.com>

> If you want me to to explain, you'll have to point me to the part you
> 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
> a different inode, and will reside in a different filesystem).

Thanks.  That; explains it for me.  Although not ideal since you said it
change resource ID's and we know it might not "fully complete", that is
acceptable if there are no resources with two bindings to them being moved.
And even that's fine if the diamonds are totally internal to the moved
As mentioned though, it is not acceptable if it breaks bindings that are
not even
part of the subtree being MOVE'd.   This is not something a client can

> > > 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
> > 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
> system supporting both (REBIND will fail for some operations, while MOVE
> won't).

:-)  Have we scared everyone away from this discussion yet?  Okay folks,
right in.  :-)
Received on Monday, 10 March 2003 15:17:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC