Re: Atomic MOVE vs BIND spec, was: Comments on the "new" 2518

On Friday, 05/12/2006 at 01:42 ZE2, Julian Reschke 
<nnjulian.reschke@gmx.de> wrote:
> Lisa Dusseault wrote:
> >
> >
> > Hoping I'm not going to beat a dead horse here, but instead offer
> > something a little different.
> >
> > Would it help everybody if the requirement wasn't made of servers at
> > all?  If the real purpose of the requirement on server behavior is to
> > set expectations for clients, well we can do that better with direct
> > requirements of clients:
> >
> >   "Clients MUST be prepared to handle complete or partial failure of a
> > MOVE request.  Partial failure could mean that some files remain at 
the
> > source while some are at the destination, or even that some files are
> > duplicated in both places.  Servers MUST NOT move partial files, a
> 
> I think that would be a change to what we say today and what RFC2518
> said. Partial failure is about member resources not being moved, not
> about individual resources being in both places. Unless you were talking
> about collection specifically, which may be true. As proposed I find
> this misleading.

I actually think what Lisa wrote is good.  It sounds to me that your issue 
is
with her saying that a resource might be left at both ends.  I don't know 
for sure
if there is a reason to say that.  If there is, I suspect you've discussed 
it
already.  I won't comment on that.

> Furthermore: what does "move partial files" mean here?

I interpret that to mean where the destination only contains the first 
block
of bytes of the file.  I'd hope that would be avoidable by writing to a
separate file and atomically renaming after the bytes are transfered.
That's why I think Lisa was willing to say MUST NOT.  (I am considering
inter-server MOVEs.) - If Lisa can confirm that I understood her
correctly, that means at least some people understand what she
means.

 
> > SHOULD NOT leave duplicate files in both places at the end of a MOVE
> > request."
> 
> If servers SHOULD NOT do that, why MUST clients expect and handle that?
> That doesn't seem to make sense from a spec language point of view.

It doesn't?  It says SHOULD NOT, not MUST NOT, so it's possible that it
can happen, right?  So the client should be prepared to deal with it, 
right?