- 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>
> 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). Thanks. That; explains it for me. Although not ideal since you said it would change resource ID's and we know it might not "fully complete", that is probably 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 subtree. 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 recover from. > > > 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). :-) Have we scared everyone away from this discussion yet? Okay folks, jump right in. :-)
Received on Monday, 10 March 2003 15:17:08 UTC