fixes for bugs in error handling in rsync-2.5.2; and updates for rsync3.txt

[Greg A. Woods]

[ On Wednesday, March 27, 2002 at 17:25:07 (+1100), Martin Pool wrote: ]
> Subject: Re: fixes for bugs in error handling in rsync-2.5.2; and updates for rsync3.txt
>
> Hi, thanks for the patch and comments on rsync3.  I'm in the process
> of committing these patches to the 2.6.0 branch.

Thanks!

> I want to get a stable 2.5 out to give people some relief for the
> recent burst of fixes, and I think in this case it's probably better
> to live with the devil we know.

Well, I don't know about that -- the main reason for my fix is that
2.5.2 broke quite a number of scripts that could no longer discern the
reason for many types of failuers!

There's some rumour from one of the NetBSD folks that fixes in 2.5.3, or
maybe it's 2.5.4, are equivalent to mine, though I've not had a chance
to test that theory yet.


> > *** main.c	6 Feb 2002 21:20:49 -0000	1.140
> > ***************
> > *** 880,887 ****
> >   
> >   	ret = start_client(argc, argv);
> >   	if (ret == -1) 
> > ! 	    exit_cleanup(RERR_STARTCLIENT);
> >   	else
> > ! 	    exit_cleanup(ret);
> > ! 	return ret;
> >   }
> >   
> >   	ret = start_client(argc, argv);
> >   	if (ret == -1) 
> > ! 		exit_cleanup(RERR_STARTCLIENT);
> >   	else
> > ! 		exit_cleanup(ret);
> > ! 
> > ! 	exit(ret);
> > ! 	/* NOTREACHED */
> >   }
> 
> Is the change to call exit() rather than returning from main meant to
> change behaviour, or is it just for consistency?

Well the call to exit() is more than just for consistency -- many Unix
platforms violate the ANSI C standard and require that exit() be called
since a 'return' from main() doesn't work the same way.  Portable code
should never just return from main().

(the whitespace fixes to the exit_cleanup() lines are cosmetic though :-)


> I liked your ideas about detecting renamed files.

Thanks!

>  Because we pipeline
> signature generation at the moment, it would not be straightforward to
> implement but it might well be possible.

I wouldn't expect what I've suggested to be quick or easy to implement
in the current infrastructure....   :-)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>