RE: MOVEs across file systems

> Anyway... the thought I just wanted to point out is that if you have a
> resource on one file system with multiple bindings to it, and you MOVE
> that resource via one of those bindings "to another file system"...
> you might actually want to NOT "copy/delete" it since you 
> still also have
> several bindings to it from the original file system.  You might
> *need* to keep a cross file system binding and not necessarily
> move implementations around during MOVE/BIND and other
> namespace operations.  And if you're forced to support cross
> file system bindings, then perhaps you never really need to take the
> COPY/DELETE approach?

A couple counter-reasons: 
 - Quota within the system (top level directories or lower directories
limiting space) this may depend on how the quota is counted - the
system, through its acknowledged limitations, may need to actually move
the resources (not leave them and rebind them) in order to calculate
quota.

 - Disk space outside the system - different parts of the namespace are
frequently literally stored on different disks. Users/Administrators may
move content from one part of the namespace to another *in order* to
transfer to a less-used disk.

Jason, you've clearly got the right instincts for designing a WebDAV
server -- thinking carefully about how to do the best possible job.
It's just a question of can the *protocol* enforce a good job on server
implementors?  Sometimes it can, but sometimes it can't. We wouldn't
want to force atomic DELETEs and have an implementation choose to reject
a great number of large DELETE requests just because it can't guarantee
them all atomic. In the extreme, that would be an even worse tradeoff.

Lisa

Received on Tuesday, 11 March 2003 11:27:50 UTC