Re: Fun with Moves and Copy

   From: "Kevin Wiggen" <wiggs@wiggenout.com>

   "If the resource exists at the destination and the Overwrite header is =
   "T" then prior to performing the move the server MUST perform a DELETE =
   with "Depth: infinity" on the destination resource."
   Wow that's a STRONG statement.

When it comes to DELETE, you really want to know what the server will
do.  A statement like "the server MAY do a DELETE" will not make you a
happy camper if you get used to one that doesn't (i.e. does some kind
of merge operation), and then try the same operation on a server that does
the DELETE.

   If you point a IE browser at a webdav server (or if you play webdav =
   server in your spare time), and you do a MOVE to a directory that =
   already exists:

   IE  =3D>  MOVE http://foo/bar  to http://foo/fee/bar Overwrite =3D F
   I respond =3D> 412 Precondition Failed
   IE  displays to user :

   This folder already contains a folder named 'bar'.

So far so good.

   If the files in the existing folder have the same name as files in the =
   folder you are moving, they will be replaced.  Do you still want to move =
   the folder?

Using the term "move" for a "merge" is rather bogus, but with the
prefacing statement, the user will know what they meant.

   If I say yes
   IE  =3D>  MOVE http://foo/bar to http://foo/fee/bar Overwrite =3D T

OK, if that's what IE does, the IE implementors were not reading the spec
very carefully (or even, very cursorily :-).  Or maybe there was an
earlier version of the spec that didn't make this clear.  At any rate,
either the prompt or the request is wrong. 

   Hang on a second...  Where is the big message saying "ALL INFO IN THE =
   DESTINATION FOLDER WILL BE LOST"

Exactly.

   Now granted IE does not do everything correctly when it comes to move =
   (again if I am wrong here please tell me, I am simply playing server).  =
   If I give IE a 207 response telling it that some subdirectory didn't =
   move because 412 Precondition Failed, IE assumes the whole move failed.  =

This is an incorrect assumption, but a compatible with the previous
incorrect assumption (i.e. that "move overwrite" means "merge").

   Which means my display in IE is screwed up and allows me to ask for =
   directories that no longer exist....  So it seems that the only =
   responses to MOVE and COPY are succeeded or failed.  =20

I'm not sure what you mean by "the only responses".  It is true that they
either succeed or fail (but with various flavors of each).  If you mean
that IE is assuming that when MOVE or COPY are done, a failure means no
change on the server, then IE is counting on things the protocol does
not provide.

   But back to the BIG DELETE problem, what happens if the big delete fails =
   for some reason???  What is the error code there?  Do I still do a =
   MOVE??? =20

That is an excellent question.  As far as I can tell, the spec is silent
on that point.  I think the only sensible thing to do is to fail the
MOVE and leave the rubble lying on the server (:-).  In any case, it would
be worth adding some words here.

   Go through that scenario

   IE =3D> MOVE http://foo/bar to http://foo/fee/bar Overwrite =3D T

   My server sees that http://foo/fee/bar exists, therefore does a DELETE =
   with Depth Infinity.  BUT that command gives back a 207 saying that some =
   downwind resource was Locked by someone else or something.  Therefore =
   the entire directory tree WAS NOT deleted, and a skeleton still remains.

Yes, the 207 sounds like the right thing to do.

   What do I do then??

   1)  Fail the Move, give IE a 412 or something.  But somehow tell IE "and =
   o yea I didn't do the move, but blew away everything I could at the =
   destination", unless I can rollback the delete somehow.

The contents of the 207 multi-status should give IE the data it needs to
know what got deleted.  If it ignores it, then there's not much you can do.

   2)  Try to do the Move, and only move the things that I can.  But if I =
   do that logic, why don't I do this in the first place and not kill off =
   all the data at destination???  I have a overwrite flag to Y therefore I =
   know to actually overwrite.

That would be a "merge", not a "move" (a "move" is basically a "rename",
extended to handle cross-server renames).

   and what is the alternative for a client if they DON'T want the Move to =
   destroy the directory??  They could call individual Moves for each file =
   I guess, but that could be quite costly.

I agree that a "collection-merge" method would be useful.  But we need
to clearly distinguish it from a "move".

   Also what happens if I have Write permission on a file, and not Delete =
   permission??  If I do the delete first it will fail, and then I will do =
   the write during the move and copy and it will succeed.  That will =
   probably confuse any client...  It seems funny that a Move will act =
   differently when Delete permissions are used.  I am not trying to Delete =
   anything.  So in order to get my desired server feel, I need to set all =
   of my files to NoDelete and everything Writeable...  Try explaining that =
   to a user....

Sure, "move" is not a good way to implement "merge" (:-).

   I think that the Kill All feature of DELETE and COPY is wrong and should =
   be changed.  Again, I know of no OS that deletes first (I think, its =
   late).  The move and copy should do what they can without clearing space =
   for themselves...

Here I'll disagree strongly.  A "move" (i.e. "rename") command is essential.
A merge command is useful, but not a replacement for move.

Cheers,
Geoff

Received on Thursday, 15 April 1999 15:40:01 UTC