batch-mode fixes [was: [PATCH] fix read-batch SEGFAULT]

[Chris Shoemaker]

On Sat, May 15, 2004 at 02:20:50PM -0700, Wayne Davison wrote:
> On Sat, May 15, 2004 at 11:53:05AM -0400, Chris Shoemaker wrote:
> > Not only does the client pass the "--write-batch=pfx" argument to the
> > server, but it's actually the server calling all the batch write
> > routines.
> 
> This isn't client/server differentiated, the current code appears to
> have been written to make the sender write out the batch info, so in
> this case it's just that the server happens to be the sender.  I think
> in the original design it was imagined that people would always push
> data when they wrote out batch files (but we'd have to ask the designer
> about that).

	Thanks for clarifying.  I'm still having to remind myself that
client/server is not the same as receiver/sender.  I was introduced to rsync
with only my simple usage in mind and now I see that there are many more uses
than the simple one.

	Yes, I think you're right about the original design.  And I guess we'd
want to preserve that capability.  Or would we?
	I'm having a little trouble seeing why this was the intended 
use.  I figure, there are three cases:

   A) If you have access to both source and dest, it doesn't really matter too
much who writes the batch -- this is like the local copy case.
   B) If you have access to the dest but not the source, then you need the
client to write the batch -- and it's not far-fetched that you might have
other copies of dest to update.
   C) However, having access to source but not dest is the only case that
_requires_ the sender to write the batch -- now what's the chance that you'll
have another identical dest to apply the batch to?  And if you did, why
wouldn't you generate the batch on that dest as in case A, above?

   So, it seems to me that it's much more useful to have the receiver/client 
write the batch than sender/client, or receiver/server, or sender/server.  
But, maybe I'm just not appreciating what the potential uses of batch-mode 
are.

   Survey: so who uses batch-mode and what for?

> 
> So, it certainly makes more sense to me to have all the info be
> generated on the client side.  Unforunately, that sounds like the code
> would need to be further munged so that it outputs either from the
> sender or the receiver, depending on who is the client.  Ick.

   Yes, I'm attempting this.  For now, I'm leaving the write-batch on the
sender paths, but trying to reproduce then in the receiver.  I think the flist
is done, csums is buggy, and haven't started delta yet.

> 
> Another thing I ran into the other day was that the --read-batch code
> appears to not support a remote destination.  I tried to run a test to
> a host:some/path destination, and it complained that it couldn't write a
> local file of that name.  I don't know if this is a design constraint or
> a bug (because I haven't looked into it).

    That doesn't surprise me.  I'm still trying to figure out what is 
_supposed_ to work.

> 
> > Oh, and AFAICS, the unfortunate way to handle legacy broken servers is
> > for the client to suppress passing the --write-batch arg, otherwise
> > they'll still hang, even with new clients.
> 
> There might be other reprocussions to that, but not sending the option
> is certainly right choice if the client becomes the only one dealing
> with it.  Since the batch processing has always been marked as
> experimental (and since it appears that not many people use it), it
> would be fine to make a newer version of the code simply refuse to
> interoperate with any older versions when --write-batch was specified.

	Even if sender and receiver can each write-batch, I don't think it
makes sense to pass the arg from client to server.  If I --write-batch on the
client, either pulling or pushing, I don't want the server parsing
--write-batch and then making files on the server (which it can't anyway,
since it will crash with permission denied.)  So supressing the arg seems
right, as long as the client can do the job.  Of course, surpressing the arg
now, without the receiver handling the batch writing just breaks the
local-server case of --write-batch, which is the only case that works right
now.  :-)

   -Chris
> 
> ..wayne..