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