RE: MOVEs across file systems

> 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