Re: specifying ssh port #?
On Thu, Aug 04, 2005 at 02:33:28PM -0400, Keith Warno wrote: > Perhaps this is a lame question, but... > > is there a way to pass an SSH port # to rsync? > > At least one way I can do it is to use a small shell wrapper around ssh > and pass the port # thru the environment. Just wondering if there is an > easier way that I magically can't find. > > The reason for this is primarily because I find myself having to copy > files between some local host and some remote host that is behind a > firewall so I wind up using an ssh tunnel. What about sticking something like this in ~/.ssh/config (assuming Unix): Host remotehost Port ? -- Jos Backus jos at catnook.com -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: batch-mode fixes [was: [PATCH] fix read-batch SEGFAULT]
On Mon, May 17, 2004 at 05:18:10PM -0400, Chris Shoemaker wrote: > BTW, there is a work-around. If you don't mind duplicating the mirror > twice, one solution is to do a regular (no --write-batch) rsync update of one > copy of the mirror, and then do the --write-batch during a local to local > rsync update of another copy of the mirror. Actually, this has some real > advantages if your network connection is unreliable. That was in fact the way I envisioned us using it at work, together with multicast-based batch file distribution (but the project never got off the ground). -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [PATCH] fix read-batch SEGFAULT [WAS: --write-batch just hangs?]
On Thu, May 06, 2004 at 09:11:15AM -0700, Wayne Davison wrote: > On Wed, May 05, 2004 at 11:34:29PM -0700, Jos Backus wrote: > > On Tue, May 04, 2004 at 08:14:22PM -0400, Chris Shoemaker wrote: > > > Just so I'm on the right page, AFAICT, batch mode doesn't work _at all_. > > > > If that's the case, it could be that the batch mode code needs to be updated > > to work with recent changes to rsync. > > The batch code worked fine in the tests I ran (as long as the long- > standing --no-whole-file bug is avoided). Okay, that explains why I didn't see any problems. Thanks Wayne. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [PATCH] fix read-batch SEGFAULT [WAS: --write-batch just hangs?]
On Tue, May 04, 2004 at 08:14:22PM -0400, Chris Shoemaker wrote: > Just so I'm on the right page, AFAICT, batch mode doesn't work _at all_. If that's the case, it could be that the batch mode code needs to be updated to work with recent changes to rsync. Last time I tried running the tests (which I posted to the list) it worked fine. I haven't had a chance to try it lately though. > If anyone knows differently, please let me know. I've think I've tried > almost every possible test, including the one in the man page. Anyway, > this patch does allow me to read a batch written locally. That's a > start, at least. > > Next, I'm going to see if I can figure out the hang that I mentioned > earlier... Please keep us posted. > --Chris > > Index: generator.c > === > RCS file: /cvsroot/rsync/generator.c,v > retrieving revision 1.79 > diff -r1.79 generator.c > 48a49 > > extern int read_batch; > 216c217 > < if (whole_file == 0 || write_batch) > --- > > if (whole_file == 0 || write_batch || read_batch) Interesting. I have the exact same patch sitting in my CVS tree but I can't remember why it's there, sorry :-( -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Quick Question.
On Sat, Mar 20, 2004 at 06:59:41PM +0200, Eran Tromer wrote:
> It would have been a simple script with the extension I proposed
> ("create batch without patching",
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg09757.html).
Fwiw, I think adding this extension is a good idea.
--
Jos Backus _/ _/_/_/ Sunnyvale, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer'
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Feature Request: Multiple Streams
On Thu, Mar 11, 2004 at 04:08:49PM -0800, Clint Byrum wrote: > This looks very promising. I have two concerns: > > 1) how bad is it if one of the batch destinations isn't exactly like the > original's destination was? Are we talking corruption, or will it say > "You screwed up, try again!" ? The trees need to be identical. rsync --read-batch will bail out at the point the batch fails to apply, iIrc. This behavior could be changed if there was interest, presumably by adding a keep-going flag or something similar. > 2) The man page says > > BATCH MODE >Note: Batch mode should be considered experimental in this > version of >rsync. The interface or behaviour may change before it > stabilizes. > > ... Is that just to scare off the weaker types, or should I be wary of > using this for production work? Why don't you try it and let us know? :) It worked fine in all the tests I ran while porting the batch mode code over. Since I never managed to get anybody at work interested in actually deploying it I have not used it much since, sorry. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: how rsync works
On Wed, Nov 26, 2003 at 03:51:46PM -0800, jw schultz wrote: > OK. I've put it back up for now. This document is a > project, not an entity and i have no intention of hosting it > indefinitely. If it is a good resource it belongs on the > rsync web site but i'd like to see it under cvs so the rsync > team can update it and similar documents. Agreed. Excellent kickoff, jw. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: problem with batch mode:
On Mon, Sep 29, 2003 at 05:20:55PM +0200, Rainer Stengele wrote: > Can anybody give me a hint? Why is "delta-transmission disabled for local > transfer"? This too fails for me with rsync 2.5.6 release, but not with the version from CVS: lizzy:~/src/rsync-cvs/obj/test/rs% ls -l .. total 1433 -rw-r--r-- 1 jos staff 436738 Sep 29 12:31 new.bak -rw-r--r-- 1 jos staff 498783 Sep 29 12:29 old.zip drwxr-xr-x 2 jos staff 512 Sep 29 12:38 rs lizzy:~/src/rsync-cvs/obj/test/rs% ls -l total 1 -rw-r--r-- 1 jos staff 180 Sep 29 12:37 x lizzy:~/src/rsync-cvs/obj/test/rs% cat x cp ../new.bak ../new.zip ../../rsync -avvv --write-batch=rs ../old.zip ../new.zip cp ../new.bak ../new.zip ../../rsync -avvv --read-batch=rs ../new.zip cmp ../old.zip ../new.zip lizzy:~/src/rsync-cvs/obj/test/rs% sh x building file list ... make_file(old.zip,*,2) expand file_list to 4000 bytes, did move done send_file_list done send_files starting server_recv(2) starting pid=395 recv_file_name(old.zip) received 1 names recv_file_list done get_local_name count=1 ../new.zip generator starting pid=395 count=1 delta transmission enabled recv_generator(../new.zip,0) generating and sending sums for 0 send_files(0, ../old.zip) count=624 rem=638 blength=700 s2length=2 flength=436738 recv_files(1) starting send_files mapped ../old.zip of size 498783 calling match_sums ../old.zip old.zip built hash table hash search b=700 len=498783 match at 700 last_match=0 j=1 len=700 n=700 match at 1400 last_match=1400 j=2 len=700 n=0 match at 2100 last_match=2100 j=3 len=700 n=0 match at 2800 last_match=2800 j=4 len=700 n=0 match at 3500 last_match=3500 j=5 len=700 n=0 match at 4200 last_match=4200 j=6 len=700 n=0 match at 4900 last_match=4900 j=7 len=700 n=0 match at 5600 last_match=5600 j=8 len=700 n=0 match at 6300 last_match=6300 j=9 len=700 n=0 [snip] match at 497166 last_match=434700 j=622 len=700 n=62466 done hash search sending file_sum false_alarms=0 tag_hits=1335 matches=594 sender finished ../old.zip generate_files phase=1 send_files phase=1 recv_files(../new.zip) recv mapped ../new.zip of size 436738 got file_sum renaming ../.new.zip.0LXsPT to ../new.zip set modtime of ../new.zip to (1064863764) Mon Sep 29 12:29:02 2003 recv_files phase=1 generate_files phase=2 send files finished total: matches=594 tag_hits=1335 false_alarms=0 data=82983 recv_files finished wrote 85595 bytes read 3784 bytes 178758.00 bytes/sec total size is 498783 speedup is 5.58 _exit_cleanup(code=0, file=../rsync/main.c, line=625): about to call exit(0) send_files starting server_recv(2) starting pid=399 get_local_name count=1 ../new.zip recv_files(1) starting generator starting pid=399 count=1 delta transmission enabled recv_generator(../new.zip,0) generating and sending sums for 0 send_files(0, ../old.zip) count=624 rem=638 blength=700 s2length=2 flength=436738 old.zip sender finished ../old.zip generate_files phase=1 send_files phase=1 recv_files(../new.zip) recv mapped ../new.zip of size 436738 got file_sum renaming ../.new.zip.pAvza1 to ../new.zip set modtime of ../new.zip to (1064863764) Mon Sep 29 12:29:02 2003 recv_files phase=1 generate_files phase=2 send files finished total: matches=0 tag_hits=0 false_alarms=0 data=0 recv_files finished wrote 85535 bytes read 3784 bytes 178638.00 bytes/sec total size is 0 speedup is 0.00 _exit_cleanup(code=0, file=../rsync/main.c, line=625): about to call exit(0) lizzy:~/src/rsync-cvs/obj/test/rs% ls -l total 91 -rwx-- 1 jos staff 51 Sep 29 12:38 rs.rsync_argvs -rw--- 1 jos staff 3752 Sep 29 12:38 rs.rsync_csums -rw--- 1 jos staff 85507 Sep 29 12:38 rs.rsync_delta -rw--- 1 jos staff 79 Sep 29 12:38 rs.rsync_flist -rw-r--r-- 1 jos staff180 Sep 29 12:37 x lizzy:~/src/rsync-cvs/obj/test/rs% ls -l .. total 1433 -rw-r--r-- 1 jos staff 436738 Sep 29 12:31 new.bak -rw-r--r-- 1 jos staff 498783 Sep 29 12:29 new.zip -rw-r--r-- 1 jos staff 498783 Sep 29 12:29 old.zip drwxr-xr-x 2 jos staff 512 Sep 29 12:38 rs lizzy:~/src/rsync-cvs/obj/test/rs% Could you try again with the version in CVS? -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Syncing Multiple servers simultaneously
On Tue, Mar 11, 2003 at 07:32:07AM -0800, Vaibhav Goel wrote: > Is there a way of syncing multiple servers simultaneously from 1 source > server? Not sure if this is what you are looking for, but have you looked at the (experimental) batch mode support in recent rsync versions? -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Please test rsync-2.5.6pre2
On Mon, Jan 20, 2003 at 10:19:42PM -0600, Dave Dykstra wrote: > The second rsync-2.5.6 pre-release version is now available at: There's the popt-1.7 update (with Dave's sprintf() workaround) at http://www.catnook.com/patches/rsync-popt-1.7.diff Perhaps we can apply this after the release as it is a very low priority update; I'd just like it not to rot :) -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Please test rsync-2.5.6pre1
On Tue, Jan 14, 2003 at 09:25:34PM -0600, Albert Chin wrote: > Latest version of popt is 1.7: > ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.1.x/popt-1.7.tar.gz I just applied this version to my local copy. On FreeBSD with gcc-3.2.1 it produces a bunch of warnings about unused variables and a number of these: In file included from ../rsync/options.c:22: ../rsync/popt/popt.h:444: warning: type qualifiers ignored on function return type This article, http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00814.html does suggest that these warnings are harmless though. The patch is available at http://www.catnook.com/patches/rsync-popt-1.7.diff -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Windows and default --modify-window=0
On Thu, Jan 09, 2003 at 11:32:30AM -0600, Dave Dykstra wrote: > The only way to do it would be to modify the protocol to include the info > instead of passing a parameter. I realize this may sound like heresy, but would it not be worthwhile in terms of code simplification/robustness to break compatibility with older (protocol) versions of rsync at some point, _before_ rewriting the whole application based on librsync? Just a thought. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Simulating rdist?
On Wed, Jan 01, 2003 at 06:09:53PM -0800, [EMAIL PROTECTED] wrote: > --- Dave Dykstra <[EMAIL PROTECTED]> > wrote: > > See the BATCH MODE section in the rsync 2.5.5 man page. It's stil pretty > > new and experimental, so it may not do what you want, but currently it's the > > best that rsync can do. > > I dont quite understand. The man page mentions that it creates 4 files with > various rsync state information. > > How does this help me in propagating a src tree to N different machines? These 4 files can be used on the remote systems to update the target tree using the --read-batch option. This is more efficient because the transfer of the diff information can happen in parallel (e.g. using multicast filetransfer tools) and the source tree is only examined once instead of N times. Of course, this only works if the target trees are not changed in any other way than by using this method. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.5 SCO Unixware patch
On Mon, Dec 23, 2002 at 02:13:51PM -0800, Stephen Friedl wrote: > This is a patch to rsync 2.5.5, and it serves two purposes. The small > patches to batch.c, flist.c and log.c simply add "void" to some function > definitions so that all declarations in proto.h have full parameter lists. > > unsigned char read_batch_flags()OLD > unsigned char read_batch_flags(void)NEW > > The SCO UNIXWare compiler correctly objected to these functions not > having a prototype in scope. The fix seems to be innocuous and should > not break anything. It does seem to require a "make proto" afterwards > to rebuild proto.h Committed, thanks! I don't feel brave enough to commit the popt/popt.c change without input from others. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Some tests fail if rsync is not on path (with patch)
Fyi: I just committed the changes to the test scripts; they now all use ``$RSYNC'' to refer to the newly built executable. Please let me know if this causes any problems. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Some tests fail if rsync is not on path (with patch)
Following up on this thread, the (cosmetic) patch at
http://www.catnook.com/patches/rsync-testsuite.patch
replaces all occurrences of $rsync_bin in the testsuite with $RSYNC, for
consistency's sake (I prefer uppercase names for {ex,im}ported variables in
scripts). I would like to commit this at the end of next week.
Comments?
--
Jos Backus _/ _/_/_/ Sunnyvale, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer'
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Suggestion: rsync and direct IO
On Thu, Dec 05, 2002 at 07:39:53AM -0500, Green, Paul wrote: > But is there an OS-independent way to set this attribute? I haven't > memorized the POSIX standard, but I don't recall seeing a way to set or get > such an attribute. Fyi: Solaris has directio(3C), FreeBSD has open(..., O_DIRECT). -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync -- batch mode. bug?
On Tue, Nov 05, 2002 at 10:36:35AM -0800, ThejoKrishna wrote: > I am using the following rsync command. > > rsync --write-batch -av --stats `cat $1` -e ssh user@host:/dirPath/ Can you show us the EXACT commands you ran, possibly in a test subtree so we can reproduce the problem? E.g. in the command line above no batch file prefix is being specified. Thanks. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Some tests fail if rsync is not on path (with patch)
Fyi, I just committed the patch below to CVS. However, it appears the test scripts don't use $RSYNC consistently. The scripts still use $rsync_bin and (worse) rsync in some places. $rsync_bin is set in the top-level Makefile and rsync.fns sets $RSYNC to $rsync_bin. For consistency's sake, should we not change all of these to either $RSYNC or $rsync_bin? I'm wiling to do the work. Jos On Tue, Oct 08, 2002 at 02:21:10PM -0400, Shprentz, Joel [C] wrote: > While installing rsync on a new Sun Netra running Solaris 2.8, two tests > (chgrp and hardlinks) failed. > > I found that these tests execute rsync while other successfull tests > exectute $RSYNC. It is fortunate that my shell path was quite restricted > and that no earlier version of rsync was installed on my path. The system > would have run the chgrp and hardlinks tests with an earlier rsync if it had > found one on my path. > > The fix is to replace rsync with $RSYNC in the two tests. With those > changes, all tests pass. > > Context diffs follow: > > *** testsuite/chgrp.test.orig Tue Oct 8 11:16:33 2002 > --- testsuite/chgrp.test Tue Oct 8 11:16:48 2002 > *** > *** 31,37 > done > sleep 2 > > ! checkit "rsync -rtgvvv \"$fromdir/\" \"$todir/\"" "$fromdir" "$todir" > > exit 0 > # last [] may have failed but if we get here then we've won > --- 31,37 > done > sleep 2 > > ! checkit "$RSYNC -rtgvvv \"$fromdir/\" \"$todir/\"" "$fromdir" "$todir" > > exit 0 > # last [] may have failed but if we get here then we've won > > > > *** testsuite/hardlinks.test.orig Tue Oct 8 11:18:46 2002 > --- testsuite/hardlinks.test Tue Oct 8 11:19:00 2002 > *** > *** 31,37 > ln "$name2" "$name3" || fail "Can't create hardlink" > cp "$name2" "$name4" || fail "Can't copy file" > > ! checkit "rsync -aHvv \"$fromdir/\" \"$todir/\"" "$fromdir" "$todir" > > exit 0 > # last [] may have failed but if we get here then we've won > --- 31,37 > ln "$name2" "$name3" || fail "Can't create hardlink" > cp "$name2" "$name4" || fail "Can't copy file" > > ! checkit "$RSYNC -aHvv \"$fromdir/\" \"$todir/\"" "$fromdir" "$todir" > > exit 0 > # last [] may have failed but if we get here then we've won > > -- > > Joel Shprentz > National Imagery and Mapping Agency > Mailstop N-17 > Washington Navy Yard, Building 213 > 1200 First Street, SE > Washington, DC 20303-0001 > > 202-685-3534 > > > -- > To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html > -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Using -F and -f
On Wed, Aug 28, 2002 at 02:36:09PM +0200, [EMAIL PROTECTED] wrote: > I'm interesting in using -F and -f options to generate > delta files to transfer to other computers not connected by > network. > Someone can help me in compiling it? No need. Have a look at the --write-batch and --read-batch command line options in the manual. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch to update the included popt to 1.6.4
[Just had my DSL line reactivated after our moving house.] On Sat, Jul 27, 2002 at 12:19:43PM -0700, Wayne Davison wrote: > On Thu, 11 Jul 2002, Jos Backus wrote: > > http://www.catnook.com/patches/rsync-popt-1.6.4.patch > > I went ahead and tested this and then checked it in (since we might as > well include the newest popt if we're going to include popt with rsync). Thanks Wayne. I did not see any problems with this patch on Solaris or FreeBSD. -- Jos Backus _/ _/_/_/ Sunnyvale, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ jos at catnook.com_/_/ _/_/_/ require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch to update the included popt to 1.6.4
On Fri, Jul 12, 2002 at 01:43:34PM -0700, Wayne Davison wrote: > I'm wondering if we shouldn't just remove popt from the rsync source and > just rely on the user to install the popt package on their system prior > to compiling rsync. Configure already uses the installed popt in > preference to the included popt, so it wouldn't be hard to change this > to not have a popt fallback. > > ..wayne.. Fwiw, I agree, I just thought it would be too bold a step forward. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.5 Tru64 5.1
On Fri, Jul 12, 2002 at 01:03:33PM -0500, Dang, Tan wrote: > Also I had to change line 22 in options.c from #include "popt.h" to #include > "popt/popt.h". Any suggestions or ideas? Doesn't CFLAGS in the generated Makefile contain ``-I./popt''? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Patch to update the included popt to 1.6.4
http://www.catnook.com/patches/rsync-popt-1.6.4.patch has a patch which upgrades the popt included with rsync to the latest version, 1.6.4. The configure script had to be regenerated (with autoconf 2.53) because popt.c wants HAVE_FLOAT_H. As an aside, I have heard people complain about this version of autoconf generating scripts that break when run under bash (as /bin/sh). Comments? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/require 'std/disclaimer' -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: cronning rsync
On Thu, Jun 20, 2002 at 03:03:53PM +0100, [EMAIL PROTECTED] wrote: > ps -ef | grep 'rsync' | grep -v 'grep rsync' | grep -v 'rsync.sh' > > /dev/null > > if [ $? -eq 1 ]; then #rsync isn't running - let's launch it now > rsync [opts] user@host::/module/* . > else > echo "Rsync is still running...please wait and try again later" > fi Note that this approach inherently suffers from a race condition: what if rsync was started right after running the ps? Adrian's setlock idea avoids this cleanly. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: batch diffs
On Sun, Jun 02, 2002 at 10:40:34PM +0300, Kalev Soikonen wrote:
> Digging around in the sources (uhg), I found that this occurs because...
> batch.c line 485 dereferences s->sums[i] which is NULL, because... generator
> thinks it can disable_deltas_p() when batches are read.
Ouch. This sounds remarkably similar to something Dave Dykstra wrote on
Wed, 23 Jan 2002:
So, I hadn't gotten a chance to try your patch, but Martin checked in your
changes into CVS and I pulled them back out of there and tried them out.
It is definitely working better. I'm still seeing a rsync_argvs file
getting created in my home directory on the remote machine; --read-batch
is also printing out "batch file extension" with two different numbers so
that was my clue. One time I accidentally tried use --read-batch to
directory that didn't match the destination directory that was present
when --write-batch created the files, and then it core dumped at batch.c
line 487:
if ((s->sums[i].sum1 != file_sum1) ||
(memcmp
(s->sums[i].sum2, file_sum2,
csum_length) != 0)) {
*checksums_match = 0;
and gdb said that s->sums[i] was a bad address. s->sums[0] was OK, but i
was 487. So, more care needs to be taken with making sure that the
new destination matches the original destination.
Because disable_deltas_p() currently returns true in recv_generator():446,
s->count == 0 but since read_batch_csum_info() does not check if s->count > 0
before trying to derefence s->sums[]i, rsync crashes. So for additional
robustness read_batch_csum_info() should check s->count. Does that sound
reasonable?
> I'm not sure about the usefulness of this batch support, but the ability
> to create rsync diffs would be awesome. (Without updating the destination,
> and why all that checksum data?) Would it not be better to provide separate
> utiliti(es) for this purpose and not clutter up rsync code?
Ideally, yes. Currently, rsync's batch mode is the only method of creating and
using diffs this way that I am aware of.
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Status Query - Please respond - Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
On Thu, May 09, 2002 at 04:22:45PM -0700, Martin Pool wrote: > shutdown(fd, 1); Perhaps use SHUT_WR instead of 1? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: "error in rsync protocol data stream"
On Tue, Apr 30, 2002 at 08:57:52AM -0400, Scott Lipcon wrote: > I just upgraded back to 2.5.5 (actually 2.5.5_1, from the FreeBSD > Ports tree - the _1 means its been patched I think) and the problem > seems to have disappeared. Maybe it was a zlib problem dealing with > a specific data pattern or something? I'll leave it at 2.5.5 and see > if I can reproduce the error in the next few days. Yes. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=36998 for the complete story. The PORTREVISION should probably have been bumped after this. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync & ssh & a specific Port
On Mon, Apr 29, 2002 at 06:53:54PM -0400, Administrator wrote:
> If someone could show me how to tell rsync to use a specific ssh port I would really
>appreciate it.
One solution would be to create an ssh wrapper script, like this:
#!/bin/sh
exec ssh -p "$@"
and refer to it instead of ssh using -e (i.e. ``-e myssh'').
Another solution would be to consult the ssh manpage and look at the ways one
can force ssh to use different options on a per host basis. In this case you
would use the Port directive in /etc/ssh/ssh_config or ~/.ssh/config:
Host myhost
Port
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch to avoid 'Connection reset by peer' error for rsync on cygwin
On Fri, Apr 26, 2002 at 05:40:07PM +0100, Max Bowsher wrote: > Action of the function depends on the value of howto - > SHUT_RD - read half of the connection is closed. The data currently in the > socket receive buffer is discarded. > SHUT_WR - write half of the connection is closed. The data in the socket send > buffer is sent followed by the normal TCP connection termination sequence. > SHUT_RDWR - both read and write halves of the connection are closed. Slightly off-topic (sorry) but interesting perhaps: had socket() been designed to return an int[2] (like pipe() and socketpair()), shutdown() would not have been necessary and one could have just used close() on each descriptor instead. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync and missing files?
On Thu, Apr 25, 2002 at 12:18:59PM -0500, Dave Dykstra wrote: > The code is currently doing a "continue" after that error, not an exit, so > it should be continuing on to do the rest of the files before it exits. > However, an error message is printed at exit time. It sounds like the files rsync can't find are the last files it tried to operate on before exiting; hence, no bug. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync and missing files?
On Tue, Apr 23, 2002 at 01:18:30PM -0500, John Madden wrote: > >> Well, since this was the only response, are we looking at the > >> possibility of this being the default behavior? > > > > I don't think it would be a good idea to have qmail-specific locking in > > rsync. > > Agreed - and I don't run qmail anyway (courier), but I thought he meant > "some form of locking." Indeed. I was talking about adding locking to the wrapper that runs the backup process (which in turn uses rsync), not to rsync itself. Application-specific hacks do not belong in rsync. > >> I'd be quite happy with rsync just throwing a warning and going to the > >> next file, or at least there being an option to turn on such behavior. > > > > Isn't that the current behaviour? > > No, not at all. As per my original post, rsync will complain about the list > of files it can't open and then just exit. At least, that's what it appears > to be doing! Hm, perhaps that can be fixed. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch: update popt/ to 1.5.1
On Mon, Apr 22, 2002 at 09:30:50AM -0701, Jos Backus wrote: > > Has someone from FreeBSD has already pushed the patch to the RedHat > > chaps? > > Not that I am aware of but I will; I'll also keep the FreeBSD port maintainer > in the loop. I have notified the popt maintainer of some problems I am having with the latest version, 1.6.4, and am now waiting for his response. Once these issues have been resolved I'll repost a patch to our popt, bringing it up to date to the latest version. I am also working on getting the FreeBSD port of popt updated to the latest version as well. > I have already sent the rsync port maintainer (Cc'd) a patch for review that > replaces the use of the included popt with the separate devel/popt port. This has been done; the FreeBSD port no longer uses the bundled popt. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch: update popt/ to 1.5.1
On Mon, Apr 22, 2002 at 11:02:23PM +1000, Martin Pool wrote: > That looks fine. I do agree it's a bit hard to understand what you're > saying in the README. Yes. I'll improve on it before committing. > Has someone from FreeBSD has already pushed the patch to the RedHat > chaps? Not that I am aware of but I will; I'll also keep the FreeBSD port maintainer in the loop. I have already sent the rsync port maintainer (Cc'd) a patch for review that replaces the use of the included popt with the separate devel/popt port. > Please go ahead and commit when you're happy; perhaps add a NEWS entry. Thanks, will do. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: ports/36998: rsync requires -O2 on BSD to avoid segv?
On Sun, Apr 21, 2002 at 09:24:32PM +0200, Anders Nordby wrote: > Hm. Better make the patch like this. The ifdef was too narrow (sorry). I wonder if the #ifdef is needed. I.e. is this a GCC bug that manifests itself because of the way GCC is implemented on i386 FreeBSD, or is a problem with GCC itself that manifests itself on i386 (perhaps because it is a bug in the i386 code generator)? Jos -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: ports/36998: rsync requires -O2 on BSD to avoid segv?
Is it OK if I fix this in rsync CVS so the next release won't need this patch on FreeBSD? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync breaks on FreeBSD without -O2?(fwd from grog@FreeBSD.org) PR 36998
On Sat, Apr 20, 2002 at 08:24:43PM -0701, Jos Backus wrote:
> Here's some mail from freebsd-cvs-all
> (<[EMAIL PROTECTED]>). Bruce Evans submitted this
> workaround which has been incorporated into the FreeBSD tree. I think we
> should do the same. I can do the honors :-)
Index: zlib/infcodes.c
===
RCS file: /data/cvs/rsync/zlib/infcodes.c,v
retrieving revision 1.3
diff -u -r1.3 infcodes.c
--- zlib/infcodes.c 2002/03/12 01:14:58 1.3
+++ zlib/infcodes.c 2002/04/21 03:28:49
@@ -197,8 +197,13 @@
c->mode = COPY;
case COPY: /* o: copying bytes in window, waiting for space */
f = q - c->sub.copy.dist;
- while (f < s->window) /* modulo window size-"while" instead */
-f += s->end - s->window;/* of "if" handles invalid distances */
+ {
+ /* XXX work around a gcc bug. */
+ volatile inflate_blocks_statef *s1 = s;
+
+ while (f < s1->window)/* modulo window size-"while" instead */
+f += s1->end - s1->window; /* of "if" handles invalid distances */
+ }
while (c->len)
{
NEEDOUT
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync breaks on FreeBSD without -O2?(fwd from grog@FreeBSD.org) PR 36998
On Sat, Apr 20, 2002 at 07:37:12PM -0700, Martin Pool wrote: > Apparently rsync breaks on FreeBSD if you turn off -O2 (which is the > default.) The breakage is apparently inside zlib. > > You'd have to think it was a compiler bug, but perhaps not. > > I haven't tried to reproduce it yet. Here's some mail from freebsd-cvs-all (<[EMAIL PROTECTED]>). Bruce Evans submitted this workaround which has been incorporated into the FreeBSD tree. I think we should do the same. I can do the honors :-) Jos On Sat, Apr 20, 2002 at 04:01:29PM -0700, Jos Backus wrote: > On Sat, Apr 20, 2002 at 01:22:16PM -0700, Kris Kennaway wrote: > > On Sat, Apr 20, 2002 at 01:19:47PM -0700, Anders Nordby wrote: > > > anders 2002/04/20 13:19:47 PDT > > > > > > Modified files: > > > net/rsyncMakefile > > > Log: > > > Make port set -O2 in CFLAGS. Necessary for -z (compress) option to work > > > properly. > > > > Err, this sounds like the fault of the broken zlib code we had in the > > source tree, which was already fixed. > > rsync uses it's own slightly incompatible version of zlib. If you can point me > to a fix I can discuss the fix with the rsync folks and commit it. > > (If you don't hear from me it's because XO cut my DSL line - I'm in the > process of switching providers.) Here's the fix from bde which I applied to the libz in the tree: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libz/infcodes.c.diff?r1=1.3&r2=1.4 Kris -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Patch: update popt/ to 1.5.1
This patch updates the files under popt/ to the latest vendor drop. The only change is the inclusion of a FreeBSD-specific patch to popt.c. This is needed in case somebody decides to build rsync on that platform without using the port. I'm not happy about the wording in popt/README.rsync so I may change it. The patch is available at http://www.catnook.com/rsync-popt-1.5.1.patch Comments welcome! (Note that I will be losing DSL connectivity for a week any moment now while I switch providers.) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: [PATCH] --soften-links option (fwd from md@Linux.IT) Re: rsync and debian mirrors
On Fri, Apr 19, 2002 at 06:05:15AM -0700, Martin Pool wrote: > Any thoughts? > > I have half a mind to turn it on by default, but I guess it's better > not to. Looks good to me; I can imagine how this could be useful. I would not turn it on by default because the default behavior alerts the user to the fact that file filesystem organization is different, and the user should consciously choose to have rsync cater for this situation. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync and missing files?
On Wed, Apr 17, 2002 at 10:57:56AM -0500, John Madden wrote: > send_files failed to open //home/user/Maildir/new/_dwG.NeZv8.blah: No such > file or directory > rsync error: partial transfer (code 23) at main.c(578) This looks slightly problematic. While Maildir delivery guarantees that files in new/ will always be complete/present, no such guarantee exists for retrieval/access. There is a race between stat'ing the source files and sending file data in the sender and any external process (a program such as qmail-pop3d in this case) which removes the source files. One way around this would be to use a lock file to coordinate access to the Maildir between the backup process and the POP daemon. This isn't too intrusive; while the lock is present, mail delivery can still take place. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: --delete-after-fetch mode?
On Tue, Apr 09, 2002 at 11:05:51AM +1000, Martin Pool wrote: > I think what you want is the proposed --move option, which would > delete the files after they're transferred. However, your example > points out a critical problem with --move: it will always race with > other applications writing to the file. If your mail delivery agent > delivers a message while rsync is transferring the file, you might get > none, some, or all of it on the destination, and the rest might be > lost. > > If you can ensure that this is not going to happen (by shutting down > the mda or locking the mailbox), or you don't care, then you can do > it. Fwiw, the Maildir delivery algorithm seems to be resistant against this. Transferring the cur and new directories in a Maildir should be safe. See http://cr.yp.to/proto/maildir.html for details. Of course, this only applies when you are using Maildir-style mailboxes. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Bug in compile of rsync 2.5.4 on Tru64 UNIX V5.1a using cc
On Thu, Mar 21, 2002 at 04:45:53PM -0500, Paul Haas wrote: > Here's how I would fix it: See patches/jos-solaris-sizet.diff for my fix. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: [dillon@FreeBSD.org: cvs commit: src/sys/net zlib.c]
On Wed, Mar 20, 2002 at 10:35:41AM -0801, Jos Backus wrote: > What about this one? The diff looks like this: Never mind, it looks like we are already doing the right thing in infblock.c. Sorry for the false alert. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
[dillon@FreeBSD.org: cvs commit: src/sys/net zlib.c]
What about this one? The diff looks like this: --- src/sys/net/zlib.c 2002/02/17 17:35:18 1.11 +++ src/sys/net/zlib.c 2002/03/20 04:05:26 1.12 @@ -10,7 +10,7 @@ * - added inflateIncomp and deflateOutputPending * - allow strm->next_out to be NULL, meaning discard the output * - * $FreeBSD: /c/ncvs/src/sys/net/zlib.c,v 1.11 2002/02/17 17:35:18 jedgar Exp $ + * $FreeBSD: /c/ncvs/src/sys/net/zlib.c,v 1.12 2002/03/20 04:05:26 dillon Exp $ */ /* @@ -3951,11 +3951,15 @@ int r; r = Z_MEM_ERROR; LEAVE } + /* +* this ZFREE must occur *BEFORE* we mess with sub.decode, because +* sub.trees is union'd with sub.decode. +*/ +ZFREE(z, s->sub.trees.blens); s->sub.decode.codes = c; s->sub.decode.tl = tl; s->sub.decode.td = td; } - ZFREE(z, s->sub.trees.blens); s->mode = CODES; case CODES: UPDATE - Forwarded message from Matt Dillon <[EMAIL PROTECTED]> - Date: Tue, 19 Mar 2002 20:05:26 -0800 (PST) From: Matt Dillon <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/net zlib.c dillon 2002/03/19 20:05:26 PST Modified files: sys/net zlib.c Log: Fix a bug introduced in 1.11 (and also MFCd to stable AND the security branch) that causes a machine to panic when the kernel PPP / DEFLATE code is used. 1.11 moved a ZFREE to a point after the structural members were clobbered by stores into a union'd structure. This commit fixes the bug and adds a big whopping comment to make sure the code isn't 'cleaned up' again :-) Ian Dowse came up with the same patch independantly 68 seconds before I did, talk about Karma! I would also like to thank Eugene Grosbein for marathon work in tracking the problem down by udpating his -stable based on date over and over again to close in on the commit that caused his crashes. PR: kern/35969 Reviewed by:Ian Dowse <[EMAIL PROTECTED]> X-MFC after: immediately Revision ChangesPath 1.12 +5 -1 src/sys/net/zlib.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe cvs-all" in the body of the message - End forwarded message - -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: posix me harder
On Thu, Mar 14, 2002 at 07:40:53AM -0500, Mike Gerdts wrote: > This does not demonstrate that test(1) is broken. First of all, pretty > much every shell these days has test as a builtin, and as such you > should be accusing sh(1), ksh(1), or similar. I know, I should have dropped the ``(1)'' from ``test(1)''. sh(1) on Solaris 8 says test Evaluate conditional expressions. See test(1) for usage and description. so I was having the reasonable expectation that the test builtin would behave identically. Turns out they forgot to apply the test(1) fixes to sh(1). So yes, it's sh(1)'s test that is broken. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Should these errors matter?
On Thu, Mar 14, 2002 at 05:00:35PM +1100, Jie Gao wrote: > This is from Solaris 7's manual for if: > > The -L option is a migration aid for users of other shells > which have similar options and may not be supported in > future releases. > > and indeed it does not support this option in this very release! -L doesn't appear to work in Solaris 8 either. However, the latest relevant standard, ``The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2001'' lists both -h and -L and says (at the end): CHANGE HISTORY Issue 6 The -h operand is added for symbolic links, and access permission requirements are clarified for the -r, -w, and -x operands to align with the IEEE P1003.2b draft standard. The normative text is reworded to avoid use of the term "must" for application requirements. The -L and -S operands are added for symbolic links and sockets. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Compile error
On Mon, Mar 11, 2002 at 08:45:44PM -0800, Jennifer Lu wrote:
> I tried to compile rsync2.5.3 on Solaris5.7, and I still
> got the same errors as Solaris5.8, can you please help
> me to look at the problem? I got error messages:
>
> Configure was run successfully, then I ran make,
> I got:
>
> "batch.c", line 408: operands have incompatible types:
> pointer to unsigned long ":" pointer to unsigned int
> cc: acomp failed for batch.c
> *** Error code 2
> make: Fatal error: Command failed for target `batch.o'
Does this patch help?
Index: batch.c
===
RCS file: /cvsroot/rsync/batch.c,v
retrieving revision 1.13
diff -u -r1.13 batch.c
--- batch.c 6 Feb 2002 21:20:48 - 1.13
+++ batch.c 12 Mar 2002 06:16:49 -
@@ -396,7 +396,7 @@
struct sum_struct *s)
{
size_t i;
-unsigned int int_zero = 0;
+size_t int_zero = 0;
extern int csum_length;
fdb_open = 1;
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: zlib 1.1.4 is out (was: Re: Patch: update zlib/* to 1.1.3)
On Tue, Mar 12, 2002 at 10:58:31AM +1100, Martin Pool wrote: > It seems the patch we merged into rsync 2.5.3 is not correct and -z is > not reliable. I'll do another release shortly. So the extra ZFREE() in infblock.c was the culprit: http://cvs.samba.org/cgi-bin/cvsweb/rsync/zlib/infblock.c.diff?r1=1.4&r2=1.5&f=h Wrt the bandaid, on both Solaris and FreeBSD the manpage says ``If ptr is NULL, no action occurs.''. So it sounds like there are platforms where free(NULL) does cause a crash. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
zlib 1.1.4 is out (was: Re: Patch: update zlib/* to 1.1.3)
I wrote: > > Hopefully they will accept your patch and there will be a 1.1.4 release, > > which also incorporates the infblock.c fixes. It would be bad to have > > different (broken) versions of zlib out there when this can easily be > > avoided. http://www.gzip.org/zlib/ says Version 1.1.4 fixes a double-free bug which creates a potential security problem described here. The beta version 1.1.5beta (to be released shortly) includes many more changes. A new official version 1.1.5 will be released as soon as extensive testing has been completed on it. See the ChangeLog for details. NOTE: zlib 1.1.4 does not support window sizes of 256 bytes (windowBits == 8). A 512-byte window is the smallest the encoder can use. (Most applications use the default 32,768-byte window size for best compression.) Now wouldn't be grand if the rsync modifications made it into that version? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Patch: update zlib/* to 1.1.3
On Mon, Mar 11, 2002 at 02:15:00PM +1100, Martin Pool wrote: > I'm going to do a three-way merge from 1.1.2->1.1.3 and 1.1.2->rsync, > and then perhaps send the patch to the upstream maintainers. Whether > they will accept it is another matter. That's what I did when I generated the patch I sent to the list a while ago. Hopefully they will accept your patch and there will be a 1.1.4 release, which also incorporates the infblock.c fixes. It would be bad to have different (broken) versions of zlib out there when this can easily be avoided. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Error building CVS on Tru64 UNIX
On Thu, Feb 21, 2002 at 05:49:03PM -0600, Albert Chin wrote: > If I case &s->count to (unsigned int *), then it compiles. How about casting to size_t * (since s->count has type size_t)? (Btw, I'll try the configure patch tomorrow and let you know). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: #3980 Re: rsync-2.5.3pre1 preview release -- please try it
On Thu, Feb 21, 2002 at 10:05:19AM -0600, Albert Chin wrote: > > gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/getaddrinfo.c -o >lib/getaddrinfo.o > > lib/getaddrinfo.c: In function `get_addr': > > lib/getaddrinfo.c:595: structure has no member named `s6_addr32' > > lib/getaddrinfo.c:597: structure has no member named `s6_addr32' > > *** Error code 1 Here are the results by configure revision: 1.128 works. 1.129: (which contains your patch) breaks. 1.130: breaks. 1.131: (head) works (regenned from fixed configure.in). > Without my patch, does it work? Unfortunately, yes (see above). > If so, the fix could be as simple as > preceding my patch with a AC_CHECK_FUNCS(getaddrinfo and running the > new code when this fails. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: #3980 Re: rsync-2.5.3pre1 preview release -- please try it
On Wed, Feb 20, 2002 at 08:31:51PM -0600, Albert Chin wrote: > > This seems to break FreeBSD... > > How? Works fine with FreeBSD 4.3-STABLE. Breaks on -current: gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c lib/getaddrinfo.c -o lib/getaddrinfo.o lib/getaddrinfo.c: In function `get_addr': lib/getaddrinfo.c:595: structure has no member named `s6_addr32' lib/getaddrinfo.c:597: structure has no member named `s6_addr32' *** Error code 1 Stop in /home/jos/src/rsync/rsync. lizzy:/usr/include# rgrep s6_addr32 ./netinet/ip_compat.h:# defineV4_PART_OF_V6(v6) v6.s6_addr32[3] ./netinet6/in6.h:#define s6_addr32 __u6_addr.__u6_addr32 ./netinet6/in6_var.h: (((d)->s6_addr32[0] ^ (a)->s6_addr32[0]) & (m)->s6_addr32[0]) == 0 && \ ./netinet6/in6_var.h: (((d)->s6_addr32[1] ^ (a)->s6_addr32[1]) & (m)->s6_addr32[1]) == 0 && \ ./netinet6/in6_var.h: (((d)->s6_addr32[2] ^ (a)->s6_addr32[2]) & (m)->s6_addr32[2]) == 0 && \ ./netinet6/in6_var.h: (((d)->s6_addr32[3] ^ (a)->s6_addr32[3]) & (m)->s6_addr32[3]) == 0 ) netinet6/in6.h has: #define s6_addr __u6_addr.__u6_addr8 #ifdef _KERNEL /*XXX nonstandard*/ #define s6_addr8 __u6_addr.__u6_addr8 #define s6_addr16 __u6_addr.__u6_addr16 #define s6_addr32 __u6_addr.__u6_addr32 #endif I wonder if we should do s/s6_addr32/s6_addr/g ? If I make that change the link succeeds at least :) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer; To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: infblock.c fixes in XFree86 source tree
On Sat, Feb 16, 2002 at 07:53:09PM -0800, Jos Backus wrote: > See http://cvsweb.xfree86.org/cvsweb/xc/lib/zlib/infblock.c, specifically rev > 1.5 and 1.6. I wonder if these apply to us as well. Also, FreeBSD has incorporated these fixes now: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libz/infblock.c.diff?r1=1.2&r2=1.3&f=h http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/zlib.c.diff?r1=1.10&r2=1.11&f=h -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
infblock.c fixes in XFree86 source tree
See http://cvsweb.xfree86.org/cvsweb/xc/lib/zlib/infblock.c, specifically rev
1.5 and 1.6. I wonder if these apply to us as well.
(It would be nice if somebody would release 1.1.4 with these and other fixes
against 1.1.{2,3}...)
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: socket.c: HAVE_SOCKADDR_LEN misspelt as HAVE_SOCK_SIN_LEN
On Wed, Feb 13, 2002 at 12:43:29PM -0600, Dave Dykstra wrote: > On Mon, Feb 11, 2002 at 12:00:55PM -0801, Jos Backus wrote: > > This causes a compile error on Solaris. Fix: Oops, I created a source tarball on FreeBSD (which has sin_len) without doing a make distclean first on Solaris (no CVS access from work). So you're right. Thanks for the checkin Dave. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Latest version of the batch mode cleanup patch
$ rsync --write-batch [other rsync options here] \nl()
- /somewhere/src_dir /somewhere/target_dir
+The fileset consists of 4 files:
+
+itemize(
+it() bf(.rsync_argvs) command-line arguments
+it() bf(.rsync_flist) rsync internal file metadata
+it() bf(.rsync_csums) rsync checksums
+it() bf(.rsync_delta) data blocks for file update & change
)
-The generated files are labeled with a common timestamp:
+The .rsync_argvs file contains a command-line suitable for updating a
+destination tree using that batch update fileset. It can be executed
+using a Bourne(-like) shell, optionally passing in an alternate
+destination tree pathname which is then used instead of the original
+path. This is useful when the destination tree path differs from the
+original destination tree path.
+
+Generating the batch update fileset once saves having to perform the
+file status, checksum and data block generation more than once when
+updating multiple destination trees. Multicast transport protocols can
+be used to transfer the batch update files in parallel to many hosts at
+once, instead of sending the same data to every host individually.
-itemize(
-it() bf(rsync_argvs.) command-line arguments
-it() bf(rsync_flist.) rsync internal file metadata
-it() bf(rsync_csums.) rsync checksums
-it() bf(rsync_delta.) data blocks for file update & change
+Example:
+
+quote(
+$ rsync --write_batch=pfx -a /source/dir/ /adest/dir/
+$ rcp pfx.rsync_* remote:
+$ rsh remote rsync --read_batch=pfx -a /bdest/dir/
+# or even
+$ rsh remote ./pfx.rsync_argvs /bdest/dir/
)
+
+In this example, rsync is used to update /adest/dir/ with /source/dir/
+and the information to repeat this operation is stored in the files
+pfx.rsync_{argvs,flist,csums,delta}. These files are then copied to
+the machine named "remote". Rsync is then invoked on "remote" to update
+/bdest/dir/ the same way as /adest/dir/. The last line shows the
+rsync_argvs file being used to invoke rsync.
+
+Caveats:
+
+The read-batch option expects the destination tree it is meant to update
+to be identical to the destination tree that was used to create the
+batch update fileset. When a difference between the destination trees
+is encountered the update will fail at that point, leaving the
+destination tree in a partially updated state. In that case, rsync can
+be used in its regular (non-batch) mode of operation to fix up the
+destination tree.
+
+The rsync version used on all destinations should be identical to the
+one used on the original destination.
+
+The -z/--compress option does not work in batch mode and yields a usage
+error. A separate compression tool can be used instead to reduce the
+size of the batch update files for transport to the destination.
+
+The -n/--dryrun option does not work in batch mode and yields a runtime
+error.
See bf(http://www.ils.unc.edu/i2dsi/unc_rsync+.html) for papers and technical
reports.
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: error in rsync protocol data stream (code 12) at token.c(288)
On Fri, Feb 01, 2002 at 01:06:15PM -0800, Jos Backus wrote:
> On Fri, Feb 01, 2002 at 02:18:06PM -0600, Dave Dykstra wrote:
> > Be careful with that, because rsync's zlib is modified from the standard.
> > Has somebody verified that the modification is not removed with the upgrade?
>
> I was under the erroneous assumption that these fixes had made it back into
> zlib-1.1.3. I'm now merging the changes made to zlib-1.1.2 by the rsync team
> back into 1.1.3, and will repost a new diff against the current rsync CVS
> soon.
OK, here's a mechanically generated version of the patch ("look Ma, no
editing!"). First I diff'ed zlib 1.1.2 against the zlib part of rsync (based
on 1.1.2) to isolate the changes that were made by the rsync people. I then
used that diff to temporarily revert those changes. I then applied the stock
zlib 1.1.2 to 1.1.3 diff against our zlib source, followed by re-applying our
changes to zlib-1.1.2. This is the result:
Index: zlib/ChangeLog
===
RCS file: /cvsroot/rsync/zlib/ChangeLog,v
retrieving revision 1.1
diff -u -r1.1 ChangeLog
--- zlib/ChangeLog 7 May 1998 06:19:41 - 1.1
+++ zlib/ChangeLog 1 Feb 2002 23:38:09 -
@@ -1,6 +1,54 @@
ChangeLog file for zlib
+Changes in 1.1.3 (9 July 1998)
+- fix "an inflate input buffer bug that shows up on rare but persistent
+ occasions" (Mark)
+- fix gzread and gztell for concatenated .gz files (Didier Le Botlan)
+- fix gzseek(..., SEEK_SET) in write mode
+- fix crc check after a gzeek (Frank Faubert)
+- fix miniunzip when the last entry in a zip file is itself a zip file
+ (J Lillge)
+- add contrib/asm586 and contrib/asm686 (Brian Raiter)
+ See http://www.muppetlabs.com/~breadbox/software/assembly.html
+- add support for Delphi 3 in contrib/delphi (Bob Dellaca)
+- add support for C++Builder 3 and Delphi 3 in contrib/delphi2 (Davide Moretti)
+- do not exit prematurely in untgz if 0 at start of block (Magnus Holmgren)
+- use macro EXTERN instead of extern to support DLL for BeOS (Sander Stoks)
+- added a FAQ file
+
+- Support gzdopen on Mac with Metrowerks (Jason Linhart)
+- Do not redefine Byte on Mac (Brad Pettit & Jason Linhart)
+- define SEEK_END too if SEEK_SET is not defined (Albert Chin-A-Young)
+- avoid some warnings with Borland C (Tom Tanner)
+- fix a problem in contrib/minizip/zip.c for 16-bit MSDOS (Gilles Vollant)
+- emulate utime() for WIN32 in contrib/untgz (Gilles Vollant)
+- allow several arguments to configure (Tim Mooney, Frodo Looijaard)
+- use libdir and includedir in Makefile.in (Tim Mooney)
+- support shared libraries on OSF1 V4 (Tim Mooney)
+- remove so_locations in "make clean" (Tim Mooney)
+- fix maketree.c compilation error (Glenn, Mark)
+- Python interface to zlib now in Python 1.5 (Jeremy Hylton)
+- new Makefile.riscos (Rich Walker)
+- initialize static descriptors in trees.c for embedded targets (Nick Smith)
+- use "foo-gz" in example.c for RISCOS and VMS (Nick Smith)
+- add the OS/2 files in Makefile.in too (Andrew Zabolotny)
+- fix fdopen and halloc macros for Microsoft C 6.0 (Tom Lane)
+- fix maketree.c to allow clean compilation of inffixed.h (Mark)
+- fix parameter check in deflateCopy (Gunther Nikl)
+- cleanup trees.c, use compressed_len only in debug mode (Christian Spieler)
+- Many portability patches by Christian Spieler:
+ . zutil.c, zutil.h: added "const" for zmem*
+ . Make_vms.com: fixed some typos
+ . Make_vms.com: msdos/Makefile.*: removed zutil.h from some dependency lists
+ . msdos/Makefile.msc: remove "default rtl link library" info from obj files
+ . msdos/Makefile.*: use model-dependent name for the built zlib library
+ . msdos/Makefile.emx, nt/Makefile.emx, nt/Makefile.gcc:
+ new makefiles, for emx (DOS/OS2), emx&rsxnt and mingw32 (Windows 9x / NT)
+- use define instead of typedef for Bytef also for MSC small/medium (Tom Lane)
+- replace __far with _far for better portability (Christian Spieler, Tom Lane)
+- fix test for errno.h in configure (Tim Newsham)
+
Changes in 1.1.2 (19 March 98)
- added contrib/minzip, mini zip and unzip based on zlib (Gilles Vollant)
See http://www.winimage.com/zLibDll/unzip.html
Index: zlib/Makefile
===
RCS file: /cvsroot/rsync/zlib/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- zlib/Makefile 7 May 1998 06:19:41 - 1.1
+++ zlib/Makefile 1 Feb 2002 23:38:09 -
@@ -22,8 +22,9 @@
LDFLAGS=-L. -lz
LDSHARED=$(CC)
+CPP=$(CC) -E
-VER=1.1.2
+VER=1.1.3
LIBS=libz.a
SHAREDLIB=libz.so
@@ -34,21 +35,27 @@
prefix = /usr/local
exec_prefix = ${prefix}
+libdir = ${exec_prefix}/lib
+includedir = ${prefix}/include
OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \
zutil.o inflate.o infblock.o inftrees.o
Re: Fix for batch mode (was Re: batch mode maintainability)
here] \e +$ rsync --write-batch=some_update [other rsync options] \e .br -/somewhere/src_dir /somewhere/target_dir +/this/source/dir /this/original/dir .RE +.RS +$ rsync --read-batch=some_update [other rsync options] \e +.br +/that/original/dir +.RE +.PP +\fBCaveats\fP: +.IP o +The read-batch option expects the destination tree it is meant to update +to be identical to the destination tree that was used to create the +batch update fileset\&. When a difference between the destination trees +is encountered the update will fail at that point, leaving the +destination tree in a partially updated state\&. In that case, rsync can +be used in its regular (non-batch) mode of operation to fix up the +destination tree\&. +.IP o +The rsync version used on all destinations should be identical to the one used +on the original destination\&. +.IP o +The -z/--compress option does not work in batch mode and yields a usage +error\&. A separate compression tool can be used instead to reduce the +size of the batch update files for transport to the destination\&. +.IP o +The -n/--dryrun option does not work in batch mode and yields a runtime +error\&. .PP -The generated files are labeled with a common timestamp: -.PP -.IP o -\fBrsync_argvs\&.\fP command-line arguments -.IP o -\fBrsync_flist\&.\fP rsync internal file metadata -.IP o -\fBrsync_csums\&.\fP rsync checksums -.IP o -\fBrsync_delta\&.\fP data blocks for file update & change -.PP -See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and technical -reports\&. +See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and +technical reports\&. .PP .SH "SYMBOLIC LINKS" .PP -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: error in rsync protocol data stream (code 12) at token.c(288)
On Fri, Feb 01, 2002 at 02:18:06PM -0600, Dave Dykstra wrote: > Be careful with that, because rsync's zlib is modified from the standard. > Has somebody verified that the modification is not removed with the upgrade? I was under the erroneous assumption that these fixes had made it back into zlib-1.1.3. I'm now merging the changes made to zlib-1.1.2 by the rsync team back into 1.1.3, and will repost a new diff against the current rsync CVS soon. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
at was used to create the +batch update fileset\&. When a difference between the destination trees +is encountered the update will fail at that point, leaving the +destination tree in a partially updated state\&. In that case, rsync can +be used in its regular (non-batch) mode of operation to fix up the +destination tree\&. +.IP o +The rsync version used on all destinations should be identical to to the +one used on the original destination\&. +.IP o +The -z/--compress option does not work in batch mode and yields a usage +error\&. A separate compression tool can be used instead to reduce the +size of the batch update files for transport to the destination\&. +.IP o +The -n/--dryrun option does not work in batch mode and yields a runtime +error\&. .PP -The generated files are labeled with a common timestamp: -.PP -.IP o -\fBrsync_argvs\&.\fP command-line arguments -.IP o -\fBrsync_flist\&.\fP rsync internal file metadata -.IP o -\fBrsync_csums\&.\fP rsync checksums -.IP o -\fBrsync_delta\&.\fP data blocks for file update & change -.PP -See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and technical -reports\&. +See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and +technical reports\&. .PP .SH "SYMBOLIC LINKS" .PP -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
nd data block generation more than once when updating +multiple source directory trees\&. Multicast transport protocols can be used +to transfer the batch update files in parallel to many hosts at once, instead +of sending the same data to every host individually\&. +.PP +Example: +.PP .RS -$ rsync --write-batch [other rsync options here] \e +$ rsync --write-batch=some_update [other rsync options] \e .br -/somewhere/src_dir /somewhere/target_dir +/this/source/dir /this/original/dir .RE +.RS +$ rsync --read-batch=some_update [other rsync options] \e +.br +/that/original/dir +.RE +.PP +\fBCaveats\fP: +.IP o +The read-batch option expects the source directory tree it is meant to update +to be identical to the source directory tree that was used to create the batch +update fileset\&. When a difference between the source directory trees is +encountered the update will fail at that point, leaving the source directory +tree in a partially updated state\&. In that case, rsync can be used in its +regular (non-batch) mode of operation to fix up the source directory tree\&. +.IP o +The -z/--compress option does not work in batch mode and yields a usage +error\&. +.IP o +The -n/--dryrun option does not work in batch mode and yields a runtime +error\&. .PP -The generated files are labeled with a common timestamp: -.PP -.IP o -\fBrsync_argvs\&.\fP command-line arguments -.IP o -\fBrsync_flist\&.\fP rsync internal file metadata -.IP o -\fBrsync_csums\&.\fP rsync checksums -.IP o -\fBrsync_delta\&.\fP data blocks for file update & change -.PP -See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and technical -reports\&. +See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and +technical reports\&. .PP .SH "SYMBOLIC LINKS" .PP -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
On Thu, Jan 24, 2002 at 06:19:56PM -0801, Jos Backus wrote: > OK, I may need help with the markup part though, so I'll post a rough draft > here first. Here's my first attempt at improving the documentation of the batch mode feature. This is the manpage only; I'll attempt to update the yodl file once everybody is satisfied with the wording, but I have no way to check it. When people are happy with the docs I'll resubmit my batchmode cleanup patch. Comments/suggestions welcome. Index: rsync.1 === RCS file: /cvsroot/rsync/rsync.1,v retrieving revision 1.108 diff -u -r1.108 rsync.1 --- rsync.1 29 Jan 2002 21:52:56 - 1.108 +++ rsync.1 31 Jan 2002 01:51:16 - @@ -306,8 +306,8 @@ --log-format=FORMAT log file transfers using specified format --password-file=FILEget password from FILE --bwlimit=KBPS limit I/O bandwidth, KBytes per second - --read-batch=FILE read batch file - --write-batch write batch file + --write-batch=PREFIXwrite batch fileset starting with PREFIX + --read-batch=PREFIX read batch fileset starting with PREFIX -h, --help show this help screen @@ -801,12 +801,13 @@ result is an average transfer rate equalling the specified limit\&. A value of zero specifies no limit\&. .IP -.IP "\fB--read-batch\fP" -Apply a previously generated change batch\&. -.IP -.IP "\fB--write-batch\fP" -Generate a set of files that can be transferred -as a batch update\&. +.IP "\fB--write-batch=PREFIX\fP" +Generate a set of files that can be transferred as a batch update\&. Each +filename in the set starts with \fBPREFIX\fP. +.IP +.IP "\fB--read-batch=PREFIX\fP" +Apply a previously generated change batch, using the fileset whose filenames +start with \fBPREFIX\fP\&. .IP .PP .SH "EXCLUDE PATTERNS" @@ -913,29 +914,50 @@ \fBNote:\fP Batch mode should be considered experimental in this version of rsync\&. The interface or behaviour may change before it stabilizes\&. .PP -The following call generates 4 files that encapsulate the information -for synchronizing the contents of \fBtarget_dir\fP with the updates found in -\fBsrc_dir\fP -.PP +Batch mode adds the ability to generate control information which describes +the changes that need to be made in order to turn a source directory tree into +a target directory tree. This control information is stored in 4 files which +have a common, user-defined prefix: +.PP +.IP o +\fB.rsync_argvs\fP command-line arguments +.IP o +\fB.rsync_flist\fP rsync internal file metadata +.IP o +\fB.rsync_csums\fP rsync checksums +.IP o +\fB.rsync_delta\fP data blocks for file update & change +.PP +This control information can be used to update an identical source directory +tree (on another system perhaps) to the state of the target directory tree. +.PP +Example: +.PP .RS -$ rsync --write-batch [other rsync options here] \e +$ rsync --write-batch=some_update [other rsync options] \e .br -/somewhere/src_dir /somewhere/target_dir +/this/src_dir /this/target_dir .RE +.RS +$ rsync --read-batch=some_update [other rsync options] \e +.br +/that/target_dir +.RE +.PP +Note that in addition to creating the batch control files, the write-batch +option also makes the target directory tree identical to the source directory +tree. +.PP +Batch mode is useful when applying the same set of updates to many identical +systems. Generating the batch control files once saves having to perform the +file status, checksum and data block generation more than once when updating +multiple source directory trees. Multicast transport protocols can be used to +transfer the control files, instead of sending the same data to every host. +.PP +\fBCaveat\fP: The -z/--compress option does not work in batch mode. .PP -The generated files are labeled with a common timestamp: -.PP -.IP o -\fBrsync_argvs\&.\fP command-line arguments -.IP o -\fBrsync_flist\&.\fP rsync internal file metadata -.IP o -\fBrsync_csums\&.\fP rsync checksums -.IP o -\fBrsync_delta\&.\fP data blocks for file update & change -.PP -See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and technical -reports\&. +See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and +technical reports\&. .PP .SH "SYMBOLIC LINKS" .PP -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Patch: update zlib/* to 1.1.3
This patch (apologies for the size) updates zlib/* to the files that ship with
zlib 1.1.3.
Index: zlib/ChangeLog
===
RCS file: /cvsroot/rsync/zlib/ChangeLog,v
retrieving revision 1.1
diff -u -r1.1 ChangeLog
--- zlib/ChangeLog 7 May 1998 06:19:41 - 1.1
+++ zlib/ChangeLog 30 Jan 2002 01:12:41 -
@@ -1,6 +1,54 @@
ChangeLog file for zlib
+Changes in 1.1.3 (9 July 1998)
+- fix "an inflate input buffer bug that shows up on rare but persistent
+ occasions" (Mark)
+- fix gzread and gztell for concatenated .gz files (Didier Le Botlan)
+- fix gzseek(..., SEEK_SET) in write mode
+- fix crc check after a gzeek (Frank Faubert)
+- fix miniunzip when the last entry in a zip file is itself a zip file
+ (J Lillge)
+- add contrib/asm586 and contrib/asm686 (Brian Raiter)
+ See http://www.muppetlabs.com/~breadbox/software/assembly.html
+- add support for Delphi 3 in contrib/delphi (Bob Dellaca)
+- add support for C++Builder 3 and Delphi 3 in contrib/delphi2 (Davide Moretti)
+- do not exit prematurely in untgz if 0 at start of block (Magnus Holmgren)
+- use macro EXTERN instead of extern to support DLL for BeOS (Sander Stoks)
+- added a FAQ file
+
+- Support gzdopen on Mac with Metrowerks (Jason Linhart)
+- Do not redefine Byte on Mac (Brad Pettit & Jason Linhart)
+- define SEEK_END too if SEEK_SET is not defined (Albert Chin-A-Young)
+- avoid some warnings with Borland C (Tom Tanner)
+- fix a problem in contrib/minizip/zip.c for 16-bit MSDOS (Gilles Vollant)
+- emulate utime() for WIN32 in contrib/untgz (Gilles Vollant)
+- allow several arguments to configure (Tim Mooney, Frodo Looijaard)
+- use libdir and includedir in Makefile.in (Tim Mooney)
+- support shared libraries on OSF1 V4 (Tim Mooney)
+- remove so_locations in "make clean" (Tim Mooney)
+- fix maketree.c compilation error (Glenn, Mark)
+- Python interface to zlib now in Python 1.5 (Jeremy Hylton)
+- new Makefile.riscos (Rich Walker)
+- initialize static descriptors in trees.c for embedded targets (Nick Smith)
+- use "foo-gz" in example.c for RISCOS and VMS (Nick Smith)
+- add the OS/2 files in Makefile.in too (Andrew Zabolotny)
+- fix fdopen and halloc macros for Microsoft C 6.0 (Tom Lane)
+- fix maketree.c to allow clean compilation of inffixed.h (Mark)
+- fix parameter check in deflateCopy (Gunther Nikl)
+- cleanup trees.c, use compressed_len only in debug mode (Christian Spieler)
+- Many portability patches by Christian Spieler:
+ . zutil.c, zutil.h: added "const" for zmem*
+ . Make_vms.com: fixed some typos
+ . Make_vms.com: msdos/Makefile.*: removed zutil.h from some dependency lists
+ . msdos/Makefile.msc: remove "default rtl link library" info from obj files
+ . msdos/Makefile.*: use model-dependent name for the built zlib library
+ . msdos/Makefile.emx, nt/Makefile.emx, nt/Makefile.gcc:
+ new makefiles, for emx (DOS/OS2), emx&rsxnt and mingw32 (Windows 9x / NT)
+- use define instead of typedef for Bytef also for MSC small/medium (Tom Lane)
+- replace __far with _far for better portability (Christian Spieler, Tom Lane)
+- fix test for errno.h in configure (Tim Newsham)
+
Changes in 1.1.2 (19 March 98)
- added contrib/minzip, mini zip and unzip based on zlib (Gilles Vollant)
See http://www.winimage.com/zLibDll/unzip.html
Index: zlib/Makefile
===
RCS file: /cvsroot/rsync/zlib/Makefile,v
retrieving revision 1.1
diff -u -r1.1 Makefile
--- zlib/Makefile 7 May 1998 06:19:41 - 1.1
+++ zlib/Makefile 30 Jan 2002 01:12:42 -
@@ -22,8 +22,9 @@
LDFLAGS=-L. -lz
LDSHARED=$(CC)
+CPP=$(CC) -E
-VER=1.1.2
+VER=1.1.3
LIBS=libz.a
SHAREDLIB=libz.so
@@ -34,21 +35,27 @@
prefix = /usr/local
exec_prefix = ${prefix}
+libdir = ${exec_prefix}/lib
+includedir = ${prefix}/include
OBJS = adler32.o compress.o crc32.o gzio.o uncompr.o deflate.o trees.o \
zutil.o inflate.o infblock.o inftrees.o infcodes.o infutil.o inffast.o
+OBJA =
+# to use the asm code: make OBJA=match.o
+
TEST_OBJS = example.o minigzip.o
-DISTFILES = README INDEX ChangeLog configure Make*[a-z0-9] *.[ch] descrip.mms \
+DISTFILES = README FAQ INDEX ChangeLog configure Make*[a-z0-9] *.[ch] *.mms \
algorithm.txt zlib.3 msdos/Make*[a-z0-9] msdos/zlib.def msdos/zlib.rc \
- nt/Makefile.nt nt/zlib.dnt amiga/Make*.??? contrib/README.contrib \
- contrib/*.txt contrib/asm386/*.asm contrib/asm386/*.c \
- contrib/asm386/*.bat contrib/asm386/zlibvc.d?? contrib/iostream/*.cpp \
+ nt/Make*[a-z0-9] nt/zlib.dnt amiga/Make*.??? os2/M*.os2 os2/zlib.def \
+ contrib/RE*.contrib contrib/*.txt contrib/asm386/*.asm contrib/asm386/*.c \
+ contrib/asm386/*.bat contrib/asm386/zlibvc.d?? contrib/asm[56]86/*.?86 \
+ contrib/asm[56]86/*.S contrib/iostream/*.cpp \
contrib/iostream/*.h contrib/iostream2/*.h contrib/iostream2/*.cpp \
contrib/untgz/Makefile contrib/untgz/*.c contrib/untgz/*.w32 \
Re: Fix for batch mode (was Re: batch mode maintainability)
On Wed, Jan 30, 2002 at 02:56:25PM -0600, Dave Dykstra wrote:
> It should do more, it should block -z from being used with --write-batch.
Or read-batch, for that matter. The second if () handles this situation:
Index: options.c
===
RCS file: /cvsroot/rsync/options.c,v
retrieving revision 1.77
diff -u -r1.77 options.c
--- options.c 25 Jan 2002 10:42:23 - 1.77
+++ options.c 30 Jan 2002 22:14:11 -
@@ -531,6 +536,22 @@
}
}
+ if (write_batch && read_batch) {
+ snprintf(err_buf,sizeof(err_buf),
+ "write-batch and read-batch can not be used together\n");
+ rprintf(FERROR,"ERROR: write-batch and read-batch"
+ " can not be used together\n");
+ return 0;
+ }
+
+ if (do_compression && (write_batch || read_batch)) {
+ snprintf(err_buf,sizeof(err_buf),
+ "compress can not be used with write-batch or read-batch\n");
+ rprintf(FERROR,"ERROR: compress can not be used with"
+ " write-batch or read-batch\n");
+ return 0;
+ }
+
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Moving files revisited
On Wed, Jan 30, 2002 at 10:21:45AM -0800, Wayne Davison wrote: > On Wed, 23 Jan 2002, Wayne Davison wrote: > > I'd like to revisit the topic of moving files from system to system > > using rsync. Fwiw (not much, I know :), this functionality is useful imo. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
On Wed, Jan 30, 2002 at 09:07:04AM -0600, Dave Dykstra wrote: > It isn't clear to me that the -z option makes sense for batch mode anyway. > Perhaps turning the rsync_* files into a gzipped tarball before sending > them to the remote machines would have better compression. I guess some > measurements would need to be done, but of course in order to do that you'd > need to have -z mode working. OK, that sounds reasonable, I'll just add a note to the batch mode description then. > What did they mean that -z was working "only while creating rsync_delta"? > Isn't that the same thing as running --write-batch? Maybe it fails on one > of the other three files it creates. No idea. It's strange that failure occurs when inflating the _second_ file. I don't really understand the code well enough to understand what's going on. Btw, what about the other patch (the one that adds --write-batch=prefix, among others), does it work for you? And can you perhaps show me how to create a setup where the batch files are created in your homedir, which is the other problem you were seeing? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
On Sat, Jan 26, 2002 at 12:02:31AM -0800, Jos Backus wrote:
> However, when I add ``-z'', rsync does fail when using a different target
> directory.
Sadly, it turns out that my test was flawed. Batch mode doesn't quite work
with -z, even when the destination directory is not changed. Not really
surprising because the original README.rsync+ says
Rsync+ implementation adds -f and -F flags.
Testing with all combinations of other rsync-supported flags has not
been extensive.
Known limitations under rsync+ code base:
under -a, -n not working and -z only while creating rsync_delta
The good news is that without -z, batch mode works properly here, even with a
different destination directory. But it would obviously be nice if -z worked
in batch mode.
When I empty d1 after the write-batch (which as a side-effect also populates
d1) and run read-batch, the read-batch only restores the first file (f1), as
can be seen below:
lizzy:~/src/rsync/batch-test% ./x
total 76
-rw--- 1 jos staff 74912 Jan 29 18:00 ktrace.out
drwxr-xr-x 2 jos staff512 Jan 17 15:08 s
-rwxr-xr-x 1 jos staff455 Jan 29 18:01 x
total 2
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2
../rsync/rsync -avz --write-batch=foo s/ d1/
rsync: building file list...
rsync: 3 files to consider.
./
XXX flist_entry=1, s-val=0
f1, len 6
XXX flist_entry=2, s-val=0
f2, len 6
wrote 172 bytes read 52 bytes 448.00 bytes/sec
total size is 12 speedup is 0.05
d1 before:
ktrace -di ../rsync/rsync -avz --read-batch=foo d1/
./
f1, len 6
YYY flist_entry=1, file_flist_entry=1
d1 after:
total 1
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1
Looking at the ktrace output, I see:
52358 rsyncGIO fd 6 wrote 34 bytes
"\^^\0\0\binflate returned -3 (0 bytes)
"
52358 rsyncRET write 34/0x22
52358 rsyncCALL sigaction(0x1e,0xbfbfe770,0xbfbfe758)
52358 rsyncRET sigaction 0
52358 rsyncCALL sigaction(0x1f,0xbfbfe760,0xbfbfe748)
52358 rsyncRET sigaction 0
52358 rsyncCALL unlink(0xbfbfed38)
52358 rsyncNAMI ".f2.8ENkb7"
52358 rsyncRET unlink 0
52358 rsyncCALL write(0x6,0x807b180,0x4f)
52358 rsyncGIO fd 6 wrote 79 bytes
"K\0\0\brsync error: error in rsync protocol data stream (code 12) at t\
oken.c(416)
"
The failure occurs in token.c:
case r_inflating:
rx_strm.next_out = (Bytef *)dbuf;
rx_strm.avail_out = CHUNK_SIZE;
r = inflate(&rx_strm, Z_NO_FLUSH);
n = CHUNK_SIZE - rx_strm.avail_out;
if (r != Z_OK) {
rprintf(FERROR, "inflate returned %d (%d bytes)\n", r,
n);
exit_cleanup(RERR_STREAMIO);
}
Any ideas on how to debug this problem?
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Solaris 2.8/2.5.2 build issues
On Mon, Jan 28, 2002 at 09:54:35AM -0500, David Birnbaum wrote: > gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c main.c -o main.o > main.c: In function `client_run': > main.c:529: warning: `flist' might be used uninitialized in this function Fixed by change the initialization to struct file_list *flist = NULL; Btw, it just occurred to me that we have a couple of places where we assign 0 or NULL to file-scoped variables. Those assignments are unnecessary, as the C standard guarantees that these variables will be set to 0. Moreover, these assignments bloat the .data section unnecessarily instead of living in the .bss section (variables in .bss will be set to 0 automatically, those in .data will be set to their respective values contained in the .data section). > options.c:271: warning: missing initializer > options.c:271: warning: (near initialization for > `long_options[0].descrip') All these can be fixed by properly padding the struct initializers with the required values. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
On Wed, Jan 23, 2002 at 11:05:15AM -0600, Dave Dykstra wrote: > One time I accidentally tried use --read-batch to directory that didn't > match the destination directory that was present when --write-batch created > the files, and then it core dumped at batch.c line 487: I don't see a coredump in this situation; read-batch works without problems here with a different directory (see one of my previous posts). However, when I add ``-z'', rsync does fail when using a different target directory. Is this what you are seeing? lizzy:~/src/rsync/batch-test% sh -x x + +PATH=../rsync:/home/jos/bitkeeper:/usr/local/Office51/bin:/usr/local/java/bin:/var/qmail/bin:/home/jos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin + prefix=foo + s=s d1=d1 d2=d2 + rm -rf d1 + rm -rf d2 + rm -f foo.rsync_argvs foo.rsync_csums foo.rsync_delta foo.rsync_flist + ls -l total 2 drwxr-xr-x 2 jos staff 512 Jan 17 15:08 s -rwxr-xr-x 1 jos staff 340 Jan 25 23:57 x + mkdir d1 + mkdir d2 + ls -l s total 2 -rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1 -rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2 + rsync -avz --write-batch=foo s/ d1/ rsync: building file list... rsync: 3 files to consider. ./ f1, len 6 f2, len 6 wrote 172 bytes read 52 bytes 149.33 bytes/sec total size is 12 speedup is 0.05 + rsync -avz --read-batch=foo d1/ wrote 12 bytes read 20 bytes 64.00 bytes/sec total size is 0 speedup is 0.00 + rsync -avz --read-batch=foo d2/ ./ f1, len 6 rsync error: received SIGUSR1 or SIGINT (code 20) at rsync.c(229) + ls -l total 8 drwxr-xr-x 2 jos staff 512 Jan 17 15:08 d1 drwxr-xr-x 2 jos staff 512 Jan 25 23:57 d2 -rwx-- 1 jos staff 39 Jan 25 23:57 foo.rsync_argvs -rw--- 1 jos staff 16 Jan 25 23:57 foo.rsync_csums -rw--- 1 jos staff 62 Jan 25 23:57 foo.rsync_delta -rw--- 1 jos staff 218 Jan 25 23:57 foo.rsync_flist drwxr-xr-x 2 jos staff 512 Jan 17 15:08 s -rwxr-xr-x 1 jos staff 340 Jan 25 23:57 x + ls -l d1 total 2 -rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1 -rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2 + ls -l d2 total 1 -rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1 -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Warning fix for main.c
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c main.c -o main.o
main.c: In function `client_run':
main.c:528: warning: `flist' might be used uninitialized in this function
Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.137
diff -u -r1.137 main.c
--- main.c 23 Jan 2002 05:51:07 - 1.137
+++ main.c 25 Jan 2002 07:21:43 -
@@ -525,7 +525,7 @@
*/
int client_run(int f_in, int f_out, pid_t pid, int argc, char *argv[])
{
- struct file_list *flist;
+ struct file_list *flist = NULL;
int status = 0, status2 = 0;
char *local_name = NULL;
extern int am_sender;
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Cosmetic fix for log.c
gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -I./popt -c log.c -o log.o
log.c: In function `log_transfer':
log.c:570: warning: unused parameter `file'
While we pass in this ``file'' parameter, why not use it and thus get rid of
this warning? The comment is kind of unclear though, any idea what the author
is trying to say exactly?
Index: log.c
===
RCS file: /cvsroot/rsync/log.c,v
retrieving revision 1.56
diff -u -r1.56 log.c
--- log.c 24 Jan 2002 02:41:38 - 1.56
+++ log.c 25 Jan 2002 07:14:17 -
@@ -559,20 +559,16 @@
}
}
-
-
-
-/* log the incoming transfer of a file for interactive use, this
- will be called at the end where the client was run
-
- it i called when a file starts to be transferred
-*/
+/*
+ * Log the incoming transfer of a file for interactive use,
+ * this will be called at the end where the client was run.
+ * Called when a file starts to be transferred.
+ */
void log_transfer(struct file_struct *file, const char *fname)
{
extern int verbose;
if (!verbose) return;
- rprintf(FINFO,"%s\n", fname);
+ rprintf(FINFO, "%s, len %lu\n", fname, (unsigned long)file->length);
}
-
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Fix for batch mode (was Re: batch mode maintainability)
On Thu, Jan 24, 2002 at 12:22:58PM -0600, Dave Dykstra wrote:
> > Yes, I'll look at doing some documentation. What about a paragraph titled
> > ``About batch mode'' with a little explanation how it works, how it differs
> > from normal rsync operation and a small example?
>
> Sounds like a good idea. Of course, refer to the section under the entries
> for --write-batch and --read-batch.
OK, I may need help with the markup part though, so I'll post a rough draft
here first.
> > > Interesting tidbit: it apparently works with -W, because I noticed that
> > > when I make a small change to a large file the rsync_delta* file is
> > > large if my original destination is on the same machine as the source
> > > (because in that case -W is implied) but if my original destination is
> > > on a remote machine the rsync_delta* file is small, and both cases
> > > produce the correct result. Maybe -W should never be implied when
> > > --write-batch is on.
> >
> > Meaning that with --write-batch you'd always get the small delta file (-W
> > turned off)?
>
> Yes.
How about the patch below? It disables the automatic setting of -W (whole file
mode) when a local target directory is specified with --write-batch.
Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.137
diff -u -r1.137 main.c
--- main.c 23 Jan 2002 05:51:07 - 1.137
+++ main.c 25 Jan 2002 02:20:00 -
@@ -656,6 +656,7 @@
extern char *shell_cmd;
extern int rsync_port;
extern int whole_file;
+ extern int write_batch;
extern int read_batch;
int rc;
@@ -709,8 +710,12 @@
p = find_colon(argv[argc-1]);
if (!p) {
local_server = 1;
- /* disable "rsync algorithm" when both sides local */
- whole_file = 1;
+ /*
+* disable "rsync algorithm" when both sides local,
+* except when creating a batch update
+*/
+ if (!write_batch)
+ whole_file = 1;
} else if (p[1] == ':') {
*p = 0;
return start_socket_client(argv[argc-1], p+2, argc-1, argv);
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
More batch mode changes, added prefix feature
On Wed, Jan 23, 2002 at 03:41:36PM -0800, Jos Backus wrote:
> Fwiw, I'm currently working on getting rid of the automatically generated
> filenames --write-batch creates, instead --write-batch should accept a suffix,
> just like --read-batch. With that working I'll convert the suffix into a
> prefix, per Dave's excellent suggestion.
The patch below implements the following:
- --write-batch now accepts a prefix as a parameter instead of generating a
timestamp suffix. --read-batch has also been changed to treat its argument
as a prefix. Updated the documentation regarding this change.
- the rsync_argvs file created now optionally uses the first parameter
supplied as the target directory.
Btw, I have not seen --read-batch with a target directory different from the
one supplied to --write-batch fail.
- In batch.c, staticized some variables.
- Shortened the code in a few places.
- Added/modified a few comments.
- Fixed a few function prototypes.
- In main.c, removed some now unused variables.
Also, see the test script and sample session below.
lizzy:~/src/rsync/batch-test% cat x
#!/bin/sh
PATH=../rsync:$PATH
prefix=foo
#rm -rf s
#mkdir s
#echo "rev 1" > s/f1
#echo "rev 1" > s/f2
rm -rf d1
rm -rf d222
rm -f $prefix.rsync_*
ls -l
mkdir d1
mkdir d222
echo s:
ls -l s
echo write-batch:
rsync -av --write-batch=$prefix s/ d1/
echo read-batch d1:
rsync -av --read-batch=$prefix d1/
echo read-batch d222:
rsync -av --read-batch=$prefix d222/
ls -l
echo d1:
ls -l d1
echo d222:
ls -l d222
lizzy:~/src/rsync/batch-test% ./x
total 2
drwxr-xr-x 2 jos staff 512 Jan 17 15:08 s
-rwxr-xr-x 1 jos staff 406 Jan 24 17:14 x
s:
total 2
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2
write-batch:
rsync: building file list...
rsync: 3 files to consider.
./
f1
f2
wrote 178 bytes read 52 bytes 460.00 bytes/sec
total size is 12 speedup is 0.05
read-batch d1:
wrote 12 bytes read 20 bytes 64.00 bytes/sec
total size is 0 speedup is 0.00
read-batch d222:
./
f1
f2
wrote 104 bytes read 52 bytes 312.00 bytes/sec
total size is 0 speedup is 0.00
total 8
drwxr-xr-x 2 jos staff 512 Jan 17 15:08 d1
drwxr-xr-x 2 jos staff 512 Jan 17 15:08 d222
-rwx-- 1 jos staff 38 Jan 24 17:15 foo.rsync_argvs
-rw--- 1 jos staff 16 Jan 24 17:15 foo.rsync_csums
-rw--- 1 jos staff 68 Jan 24 17:15 foo.rsync_delta
-rw--- 1 jos staff 218 Jan 24 17:15 foo.rsync_flist
drwxr-xr-x 2 jos staff 512 Jan 17 15:08 s
-rwxr-xr-x 1 jos staff 406 Jan 24 17:14 x
d1:
total 2
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2
d222:
total 2
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f1
-rw-r--r-- 1 jos staff 6 Jan 17 15:08 f2
The patch:
Index: batch.c
===
RCS file: /cvsroot/rsync/batch.c,v
retrieving revision 1.12
diff -u -r1.12 batch.c
--- batch.c 24 Jan 2002 08:09:46 - 1.12
+++ batch.c 25 Jan 2002 01:25:28 -
@@ -8,55 +8,38 @@
#include "rsync.h"
#include
-char rsync_flist_file[27] = "rsync_flist.";
-char rsync_csums_file[27] = "rsync_csums.";
-char rsync_delta_file[27] = "rsync_delta.";
-char rsync_argvs_file[27] = "rsync_argvs.";
-
-char batch_file_ext[15];
-
-int fdb;
-int fdb_delta;
-int fdb_open;
-int fdb_close;
+extern char *batch_prefix;
struct file_list *batch_flist;
-void create_batch_file_ext()
-{
- struct tm *timeptr;
- time_t elapsed_seconds;
-
- /* Save run date and time to use for batch file extensions */
- time(&elapsed_seconds);
- timeptr = localtime(&elapsed_seconds);
-
- sprintf(batch_file_ext, "%4d%02d%02d%02d%02d%02d",
- timeptr->tm_year + 1900, timeptr->tm_mon + 1,
- timeptr->tm_mday, timeptr->tm_hour, timeptr->tm_min,
- timeptr->tm_sec);
- rprintf(FINFO,"batch file extension: %s\n", batch_file_ext);
-}
-
-void set_batch_file_ext(char *ext)
-{
- strcpy(batch_file_ext, ext);
-}
+static char rsync_flist_file[] = ".rsync_flist";
+static char rsync_csums_file[] = ".rsync_csums";
+static char rsync_delta_file[] = ".rsync_delta";
+static char rsync_argvs_file[] = ".rsync_argvs";
+
+static int fdb;
+static int fdb_delta;
+static int fdb_open;
+static int fdb_close;
void write_batch_flist_file(char *buff, int bytes_to_write)
{
+ char filename[MAXPATHLEN];
if (fdb_open) {
/* Set up file extension */
- strcat(rsync_flist_file, batch_file_ext);
+ strlcpy(filename, batch_prefix, sizeof(filename));
+ strlcat(filename, rsync_flist_file, sizeof(filename));
- /* Open batch flist file for writing; create it if it doesn't exist */
- fdb =
-
Re: Fix for batch mode (was Re: batch mode maintainability)
Fwiw, I'm currently working on getting rid of the automatically generated
filenames --write-batch creates, instead --write-batch should accept a suffix,
just like --read-batch. With that working I'll convert the suffix into a
prefix, per Dave's excellent suggestion.
On Wed, Jan 23, 2002 at 11:05:15AM -0600, Dave Dykstra wrote:
> On Wed, Jan 23, 2002 at 04:37:53PM +1100, Martin Pool wrote:
> > On 17 Jan 2002, Jos Backus <[EMAIL PROTECTED]> wrote:
> > When you get a chance, could you please look at writing some more
> > documentation about batch mode? It would also be good to try to split
> > out the code a little more. All the if(read_batch) conditionals look
> > highly breakable.
Yes, I'll look at doing some documentation. What about a paragraph titled
``About batch mode'' with a little explanation how it works, how it differs
from normal rsync operation and a small example?
> So, I hadn't gotten a chance to try your patch, but Martin checked in your
> changes into CVS and I pulled them back out of there and tried them out.
> It is definitely working better.
Great. I was happy to see this go in, so now more people can look at it
easily. I do intend to work on it to make it more stable.
> I'm still seeing a rsync_argvs file getting created in my home directory on
> the remote machine; --read-batch is also printing out "batch file extension"
> with two different numbers so that was my clue.
Strange, that doesn't happen in my test setup. I'll poke at it.
> One time I accidentally tried use --read-batch to
> directory that didn't match the destination directory that was present
> when --write-batch created the files, and then it core dumped at batch.c
> line 487:
> if ((s->sums[i].sum1 != file_sum1) ||
> (memcmp
>(s->sums[i].sum2, file_sum2,
> csum_length) != 0)) {
> *checksums_match = 0;
> and gdb said that s->sums[i] was a bad address. s->sums[0] was OK, but i
> was 487. So, more care needs to be taken with making sure that the
> new destination matches the original destination.
Hm, I wonder if we can make this more flexible.
> Suggestion: have the rsync_argvs file take a $1 parameter as the destination
> rather than the original destination, or maybe ${1:-original_dest} so if
> a new destination is not specified it will default to the original one.
Yes, if we can fix the above problem that is a good idea.
> Interesting tidbit: it apparently works with -W, because I noticed that
> when I make a small change to a large file the rsync_delta* file is large
> if my original destination is on the same machine as the source (because in
> that case -W is implied) but if my original destination is on a remote
> machine the rsync_delta* file is small, and both cases produce the correct
> result. Maybe -W should never be implied when --write-batch is on.
Meaning that with --write-batch you'd always get the small delta file (-W
turned off)?
> - Dave Dykstra
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Fix for batch mode (was Re: batch mode maintainability)
18,7 @@
\fBsrc_dir\fP
.PP
.RS
-$ rsync -F [other rsync options here] \e
+$ rsync --write-batch [other rsync options here] \e
.br
/somewhere/src_dir /somewhere/target_dir
.RE
Index: rsync.yo
===
RCS file: /cvsroot/rsync/rsync.yo,v
retrieving revision 1.86
diff -u -r1.86 rsync.yo
--- rsync.yo18 Dec 2001 06:45:28 - 1.86
+++ rsync.yo18 Jan 2002 01:48:12 -
@@ -277,8 +277,8 @@
--log-format=FORMAT log file transfers using specified format
--password-file=FILEget password from FILE
--bwlimit=KBPS limit I/O bandwidth, KBytes per second
- -f, --read-batch=FILE read batch file
- -F, --write-batch write batch file
+ --read-batch=FILE read batch file
+ --write-batch write batch file
-h, --help show this help screen
@@ -798,7 +798,7 @@
bf(src_dir)
quote(
-$ rsync -F [other rsync options here] \nl()
+$ rsync --write-batch [other rsync options here] \nl()
/somewhere/src_dir /somewhere/target_dir
)
Index: sender.c
===
RCS file: /cvsroot/rsync/sender.c,v
retrieving revision 1.13
diff -u -r1.13 sender.c
--- sender.c31 Aug 2001 09:27:35 - 1.13
+++ sender.c18 Jan 2002 01:48:12 -
@@ -159,13 +159,14 @@
initial_stats = stats;
s = receive_sums(f_in);
- if (write_batch) /* dw */
- write_batch_csum_info(&i,flist->count,s);
if (!s) {
io_error = 1;
rprintf(FERROR,"receive_sums failed\n");
return;
}
+
+ if (write_batch)
+ write_batch_csum_info(&i,flist->count,s);
if (!read_batch) {
fd = do_open(fname, O_RDONLY, 0);
Index: util.c
===
RCS file: /cvsroot/rsync/util.c,v
retrieving revision 1.97
diff -u -r1.97 util.c
--- util.c 2 Dec 2001 14:12:03 - 1.97
+++ util.c 18 Jan 2002 01:48:13 -
@@ -173,10 +173,7 @@
extern int am_sender;
extern int am_server;
- if (read_batch)
- am_sender = 0;
- else
- am_sender = !am_sender;
+ am_sender = read_batch ? 0 : !am_sender;
am_server = 1;
if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: batch mode maintainability
On Wed, Jan 16, 2002 at 06:32:56PM -0801, Jos Backus wrote: > I'll try to investigate; it must be some interaction between the batch code > and some change that has been made in the last month. I have narrowed the changes that break batch mode (even with my patch applied) down to cvs diff -D "2002-01-11 00:00:00 PST" -D "2002-01-11 01:00:00 PST" So if you run cvs update -Pd -D "2002-01-11 00:00:00 PST" and apply my last patch you should have a working version. Also, the rsync_flist.* file contents generated differ between these versions. I'll try to investigate this further, but if anybody else has some bright ideas please let me know. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: batch mode maintainability
On Wed, Jan 16, 2002 at 02:52:08PM -0600, Dave Dykstra wrote: > I applied the patch to the current development CVS and it gets further but > still has trouble. Using the above commands, the first --write-batch now > actually copies the files in addition to creating the rsync_* files. > However, when I mkdir d2 and run the second command replacing "d1/" with > "d2/" it dumps core. Something must have been broken since I sent that last patch because the version I have here (CVS as of 12 Dec 2001) seems to work (note that my test script is slightly different from yours): lizzy:~/src/rsync/batch-test% cat x #!/bin/sh PATH=../rsync-wtv:$PATH rm -rf s d rm -f rsync_*.* mkdir s d echo "rev 1" > s/f1 echo "rev 1" > s/f2 ls -l echo s: ls -l s rsync -av --write-batch s/ d/ rsync -av --read-batch `echo rsync_argvs.*|sed 's/.*\.//'` d/ ls -l echo d: ls -l d total 3 drwxr-xr-x 2 jos staff 512 Jan 16 18:22 d drwxr-xr-x 2 jos staff 512 Jan 16 18:22 s -rwxr-xr-x 1 jos staff 247 Jan 16 18:20 x s: total 2 -rw-r--r-- 1 jos staff 6 Jan 16 18:22 f1 -rw-r--r-- 1 jos staff 6 Jan 16 18:22 f2 lizzy:~/src/rsync/batch-test% ./x batch file extension: 20020116182215 building file list ... done f1 f2 wrote 178 bytes read 52 bytes 460.00 bytes/sec total size is 12 speedup is 0.05 wrote 12 bytes read 20 bytes 64.00 bytes/sec total size is 0 speedup is 0.00 total 7 drwxr-xr-x 2 jos staff 512 Jan 16 18:22 d -rwx-- 1 jos staff 43 Jan 16 18:22 rsync_argvs.20020116182215 -rw--- 1 jos staff 16 Jan 16 18:22 rsync_csums.20020116182215 -rw--- 1 jos staff 68 Jan 16 18:22 rsync_delta.20020116182215 -rw--- 1 jos staff 182 Jan 16 18:22 rsync_flist.20020116182215 drwxr-xr-x 2 jos staff 512 Jan 16 18:22 s -rwxr-xr-x 1 jos staff 247 Jan 16 18:20 x d: total 2 -rw-r--r-- 1 jos staff 6 Jan 16 18:22 f1 -rw-r--r-- 1 jos staff 6 Jan 16 18:22 f2 > Keep in mind that by default on a local system rsync 2.5.0 and later > defaults to the -W option which disables the rsync algorithm. I thought > that might make a difference so I also tried sending to a remote machine. > First, I note that the rsync_argvs.* files are totally useless because they > completely recreate the original command line, and who wants to copy to the > exact same place twice? Yes, except that --write-batch is replaced with --read-batch, and the first directory name is bogus (with --read-batch one only has to specify the _target_ directory; see the script above). > The idea is to copy the same thing to more than one machine. Oh, maybe the > machine name is ignored with --read-batch? One would think, yes. > Nit: the rsync_argv file is missing a terminating newline. Annoying indeed but easily fixed. > I see that the remote side is also creating an extra rsync_argv.* file in > the user's home directory, please stop creating those. Hm, I don't see that behavior here. > Copying the rsync_* files to the remote side and running a --read-batch > command there also dumps core. > > Does it work for you? Yes, but not with the latest CVS, it cores there as well (I'm using FreeBSD, btw). I'll try to investigate; it must be some interaction between the batch code and some change that has been made in the last month. > - Dave -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: batch mode maintainability
ons here] \nl()
/somewhere/src_dir /somewhere/target_dir
)
Index: sender.c
===
RCS file: /cvsroot/rsync/sender.c,v
retrieving revision 1.13
diff -u -r1.13 sender.c
--- sender.c31 Aug 2001 09:27:35 - 1.13
+++ sender.c15 Jan 2002 19:07:57 -
@@ -159,13 +159,14 @@
initial_stats = stats;
s = receive_sums(f_in);
- if (write_batch) /* dw */
- write_batch_csum_info(&i,flist->count,s);
if (!s) {
io_error = 1;
rprintf(FERROR,"receive_sums failed\n");
return;
}
+
+ if (write_batch)
+ write_batch_csum_info(&i,flist->count,s);
if (!read_batch) {
fd = do_open(fname, O_RDONLY, 0);
Index: util.c
===
RCS file: /cvsroot/rsync/util.c,v
retrieving revision 1.98
diff -u -r1.98 util.c
--- util.c 15 Jan 2002 10:05:28 - 1.98
+++ util.c 15 Jan 2002 19:07:58 -
@@ -173,10 +173,7 @@
extern int am_sender;
extern int am_server;
- if (read_batch)
- am_sender = 0;
- else
- am_sender = !am_sender;
+ am_sender = read_batch ? 0 : !am_sender;
am_server = 1;
if (dup2(to_child_pipe[0], STDIN_FILENO) < 0 ||
Thanks,
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync+ tidyup (was Re: move rsync development tree to BitKeeper?)
On Thu, Jan 03, 2002 at 06:52:08PM +1100, Martin Pool wrote: > > Another thought: maybe we should reserve -f and -F for something else and > > just stick with the long options? What do you think? > > That sounds like a good idea, as long as not too many people have started > using them already. I seriously doubt anyone is using the batch feature because without the last patch I sent you it simply does not work :-) -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --owner --group without root access?
On Sun, Dec 30, 2001 at 07:40:23AM -0500, Philip Mak wrote: > Giving the situation some more thought, it might not be hard to be able to > use rsync to preserve file ownership without having root access. It would > be just a matter of getting a "ls -lR" of the data, and having some > program that can parse that to recover the original file ownership if > necessary. > > Has anyone already done something like this by any chance? Have a look at the BSD mtree(8) utility, in particular the -U option. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: [Q] multicasting product ?
On Wed, Dec 19, 2001 at 12:11:46PM +0100, Ph. Marek wrote: > Now that RSYNC has RSYNC+ included a good usage would be to use RSYNC+ to > gather update-date, then multicast that on your hosts and process it. Note that the rsync+ functionality as currently present in CVS does not work; I sent a final patch to Martin Pool for review that makes it work properly (my colleague says he's had no problems so far). Hopefully it will make it into the next stable release. mrsync looks very interesting, too. It's always nice to have more options to choose from. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync-2.5.1pre1 with -F option
'4', POPT_ARG_VAL,&global_opts.af_hint, AF_INET },
{0,'6', POPT_ARG_VAL,&global_opts.af_hint, AF_INET6 },
@@ -612,7 +612,7 @@
}
if (batch_ext != NULL) {
- sprintf(fext,"-f%s",batch_ext);
+ snprintf(fext,sizeof(fext),"--read-batch=%s",batch_ext);
args[ac++] = fext;
}
Index: proto.h
===
RCS file: /cvsroot/rsync/proto.h,v
retrieving revision 1.133
diff -u -r1.133 proto.h
--- proto.h 26 Nov 2001 07:18:09 - 1.133
+++ proto.h 11 Dec 2001 01:36:38 -
@@ -9,7 +9,7 @@
void write_batch_flist_file(char *buff, int bytes_to_write);
void write_batch_flist_info(int flist_count, struct file_struct **fptr);
void write_char_bufs(char *buf);
-void write_batch_argvs_file(int orig_argc, int argc, char **argv);
+void write_batch_argvs_file(int argc, char *argv[]);
struct file_list *create_flist_from_batch();
int read_batch_flist_file(char *buff, int len);
unsigned char read_batch_flags();
Index: rsync.1
===
RCS file: /cvsroot/rsync/rsync.1,v
retrieving revision 1.99
diff -u -r1.99 rsync.1
--- rsync.1 5 Dec 2001 13:10:24 - 1.99
+++ rsync.1 11 Dec 2001 01:36:40 -
@@ -306,8 +306,8 @@
--log-format=FORMAT log file transfers using specified format
--password-file=FILEget password from FILE
--bwlimit=KBPS limit I/O bandwidth, KBytes per second
- -f, --read-batch=FILE read batch file
- -F, --write-batch write batch file
+ --read-batch=FILE read batch file
+ --write-batch write batch file
-h, --help show this help screen
@@ -916,7 +916,7 @@
\fBsrc_dir\fP
.PP
.RS
-$ rsync -F [other rsync options here] \e
+$ rsync --write-batch [other rsync options here] \e
.br
/somewhere/src_dir /somewhere/target_dir
.RE
Index: rsync.yo
===
RCS file: /cvsroot/rsync/rsync.yo,v
retrieving revision 1.84
diff -u -r1.84 rsync.yo
--- rsync.yo5 Dec 2001 13:10:24 - 1.84
+++ rsync.yo11 Dec 2001 01:36:41 -
@@ -277,8 +277,8 @@
--log-format=FORMAT log file transfers using specified format
--password-file=FILEget password from FILE
--bwlimit=KBPS limit I/O bandwidth, KBytes per second
- -f, --read-batch=FILE read batch file
- -F, --write-batch write batch file
+ --read-batch=FILE read batch file
+ --write-batch write batch file
-h, --help show this help screen
@@ -796,7 +796,7 @@
bf(src_dir)
quote(
-$ rsync -F [other rsync options here] \nl()
+$ rsync --write-batch [other rsync options here] \nl()
/somewhere/src_dir /somewhere/target_dir
)
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Cosmetic code cleanup?
On Sat, Dec 08, 2001 at 12:07:22AM +1100, Martin Pool wrote: > Yes, I agree. I'll just run GNU indent over it and commit directly -- > no need to send a big noisy patch unless you really want to. Good plan, I wasn't sure how many issues like these GNU indent is able to fix. I'll have a look again after your commit. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Should --write-batch always sync the target tree?
Currently the --write-batch option in addition to creating the batch files
also syncs the target tree. I'm not sure whether this is always desired. So
far the only way I have been able to come up with to prevent the target tree
from being populated is the patch below; however, the top-level target
directory is still created, so it is not complete. Does this sound like a
worthwile addition to optionally speed up --write-batch? We could add a flag
for this.
Comments?
Also, I'd like us to drop the -F and -f options so we can use these short
options for something used more often - I expect not too many people to use
the rsync+ features (but I could be wrong, of course).
--- receiver.c 7 May 2001 06:59:37 - 1.33
+++ receiver.c 7 Dec 2001 02:16:04 -
@@ -36,6 +36,7 @@
extern char *compare_dest;
extern int make_backups;
extern char *backup_suffix;
+extern int write_batch;
static struct delete_list {
dev_t dev;
@@ -357,6 +358,12 @@
if (!am_server) {
log_transfer(file, fname);
}
+ continue;
+ }
+
+ if (write_batch) {
+ /* drain */
+ receive_data(f_in,NULL,-1,NULL,file->length);
continue;
}
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Cosmetic code cleanup?
Here's a list of cosmetic changes I'd be willing to make to the code in order to make it more consistent, which stylisticly it currently is not. - separate function definitions by 2 newlines - put spaces after commas in arg lists - put spaces around assignments - remove trailing spaces - change space indents to tabs - fix multiline comments - remove redundant /* dw */ comments (Deborah Weiss is already credited in the documentation) Thoughts? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync-2.5.1pre1 with -F option
Here's a better patch; rsync should now no longer dump core if called with
insufficient arguments. write_batch_argvs_file() is still ugly though, not
sure how to clean this up.
Index: batch.c
===
RCS file: /cvsroot/rsync/batch.c,v
retrieving revision 1.6
diff -u -r1.6 batch.c
--- batch.c 2 Dec 2001 22:47:30 - 1.6
+++ batch.c 6 Dec 2001 23:11:26 -
@@ -128,7 +128,7 @@
}
}
-void write_batch_argvs_file(int orig_argc, int argc, char **argv)
+void write_batch_argvs_file(int argc, char *argv[])
{
int fdb;
int i;
@@ -149,13 +149,17 @@
buff[0] = '\0';
/* Write argvs info to batch file */
- for (i = argc - orig_argc; i < argc; i++) {
- /* FIXME: This apparently crashes if rsync is run with
-* just "rsync -F". I think directly manipulating
-* argv[] is probably bogus -- what if -F is part of a
-* run of several short options? */
- if (!strcmp(argv[i], "-F")) { /* safer to change it here than script
*/
- strncat(buff, "-f ", 3);/* chg to -f + ext to get
ready for remote */
+ for (i = 0; i < argc; ++i) {
+ /*
+* FIXME: I think directly manipulating argv[] is probably
+* bogus -- what if -F is part of a run of several short
+* options?
+*/
+ if (!strcmp(argv[i], "-F") ||
+ !strcmp(argv[i], "--write-batch")) {
+ /* safer to change it here than script */
+ /* chg to -f + ext to get ready for remote */
+ strncat(buff, "-f ", 3);
strncat(buff, batch_file_ext,
strlen(batch_file_ext));
} else {
Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.134
diff -u -r1.134 main.c
--- main.c 15 Aug 2001 07:50:07 - 1.134
+++ main.c 6 Dec 2001 23:11:27 -
@@ -765,8 +765,10 @@
extern int write_batch; /* dw */
extern char *batch_ext; /* dw */
int orig_argc; /* dw */
+ char **orig_argv;
orig_argc = argc; /* dw */
+ orig_argv = argv;
signal(SIGUSR1, sigusr1_handler);
signal(SIGUSR2, sigusr2_handler);
@@ -806,7 +808,7 @@
if (write_batch) { /* dw */
create_batch_file_ext();
- write_batch_argvs_file(orig_argc, argc, argv);
+ write_batch_argvs_file(orig_argc, orig_argv);
}
if (read_batch) { /* dw */
Index: proto.h
===
RCS file: /cvsroot/rsync/proto.h,v
retrieving revision 1.133
diff -u -r1.133 proto.h
--- proto.h 26 Nov 2001 07:18:09 - 1.133
+++ proto.h 6 Dec 2001 23:11:27 -
@@ -9,7 +9,7 @@
void write_batch_flist_file(char *buff, int bytes_to_write);
void write_batch_flist_info(int flist_count, struct file_struct **fptr);
void write_char_bufs(char *buf);
-void write_batch_argvs_file(int orig_argc, int argc, char **argv);
+void write_batch_argvs_file(int argc, char *argv[]);
struct file_list *create_flist_from_batch();
int read_batch_flist_file(char *buff, int len);
unsigned char read_batch_flags();
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: move rsync development tree to BitKeeper?
On Thu, Dec 06, 2001 at 05:36:55PM -0500, Mark Eichin wrote: > GNU Subversions is apparently now self-hosting (and is actually free, > instead of arguably free :-) If you're looking at perforce or > bitkeeper, though, also look at Accurev 3.0 (which is > free-for-free-software, in java, *fast* and has a better consistency > model...) Heh, I mentioned Subversion to Martin as well :) While AccuRev is nice indeed (I think it's nicer than Perforce), I wonder if their diff command can output unified diff's. Last time I checked it could not, but maybe things have changed since. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync-2.5.1pre1 with -F option
> Program received signal SIGSEGV, Segmentation fault.
> write_batch_argvs_file (orig_argc=-2, argc=0, argv=0x0) at batch.c:153
> 153if ( !strcmp(argv[i],"-F") ){ /* safer to change it here
> than script*/
I'm not proud of this fix, but at least it makes -F/--write-batch work
properly:
Index: batch.c
===
RCS file: /cvsroot/rsync/batch.c,v
retrieving revision 1.6
diff -u -r1.6 batch.c
--- batch.c 2 Dec 2001 22:47:30 - 1.6
+++ batch.c 6 Dec 2001 02:00:05 -
@@ -150,12 +150,17 @@
/* Write argvs info to batch file */
for (i = argc - orig_argc; i < argc; i++) {
- /* FIXME: This apparently crashes if rsync is run with
-* just "rsync -F". I think directly manipulating
-* argv[] is probably bogus -- what if -F is part of a
-* run of several short options? */
- if (!strcmp(argv[i], "-F")) { /* safer to change it here than script
*/
- strncat(buff, "-f ", 3);/* chg to -f + ext to get
ready for remote */
+ /*
+* FIXME:
+* I think directly manipulating argv[] is probably
+* bogus -- what if -F is part of a run of several short
+* options?
+*/
+ if (!strcmp(argv[i], "-F") ||
+ !strcmp(argv[i], "--write-batch")) {
+ /* safer to change it here than script */
+ /* chg to -f + ext to get ready for remote */
+ strncat(buff, "-f ", 3);
strncat(buff, batch_file_ext,
strlen(batch_file_ext));
} else {
Index: main.c
===
RCS file: /cvsroot/rsync/main.c,v
retrieving revision 1.134
diff -u -r1.134 main.c
--- main.c 15 Aug 2001 07:50:07 - 1.134
+++ main.c 6 Dec 2001 02:00:05 -
@@ -765,8 +765,10 @@
extern int write_batch; /* dw */
extern char *batch_ext; /* dw */
int orig_argc; /* dw */
+ char **orig_argv;
orig_argc = argc; /* dw */
+ orig_argv = argv;
signal(SIGUSR1, sigusr1_handler);
signal(SIGUSR2, sigusr2_handler);
@@ -806,7 +808,7 @@
if (write_batch) { /* dw */
create_batch_file_ext();
- write_batch_argvs_file(orig_argc, argc, argv);
+ write_batch_argvs_file(orig_argc, argc, orig_argv + argc + 1);
}
if (read_batch) { /* dw */
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Mon, Nov 26, 2001 at 07:37:33PM +1100, Martin Pool wrote: > I'll apply something like Jos's patch, with a modification to not > create another bloody global variable but instead stick it in an > options struct. Good idea. Btw, Openssh also uses structs to pass options around. > People who work with Apache should try the mostly-undocumented -X > option, which tells it to not detach and also not fork on incoming > connections. For debugging that's even more useful. Yes, however 2.0.28 still has a problem with this; see my message with subject ``HAVE_SETSID'' problem on the apache-dev list, which unfortunately has been ignored so far. I notified the maintainer of the FreeBSD port and he told me he has submitted a bugreport to the Apache folks. So hopefully this problem will be fixed at some point. The remaining issue with ``-X NO_DETACH'' is that it keeps httpd from creating its own process group, even though it _kills_ the process group it is in. This is bad news because this process group contains svscan/supervise/etc. So what is needed for httpd is another option that only causes apr_proc_detach() to call setsid()|setpgrp()|..., not the other stuff. All this is really ugly anyway; httpd should simply keep track of its children's pid's (I bet it does already) and kill() those instead of a process group it doesn't own. S[ai]mple --no-detach manpage patch: Index: rsync.1 === RCS file: /cvsroot/rsync/rsync.1,v retrieving revision 1.95 diff -u -r1.95 rsync.1 --- rsync.1 14 Aug 2001 02:04:49 - 1.95 +++ rsync.1 26 Nov 2001 18:46:24 - @@ -296,6 +296,7 @@ --include-from=FILE don\'t exclude patterns listed in FILE --version print version number --daemonrun as a rsync daemon + --no-detach do not detach from the parent --address bind to the specified address --config=FILE specify alternate rsyncd\&.conf file --port=PORT specify alternate rsyncd port number @@ -714,6 +715,10 @@ config file (/etc/rsyncd\&.conf) on each connect made by a client and respond to requests accordingly\&. See the rsyncd\&.conf(5) man page for more details\&. +.IP +.IP "\fB--no-detach\fP" +When running as a daemon, this option instructs rsync to not detach itself and +become a background process\&. .IP .IP "\fB--address\fP" By default rsync will bind to the wildcard address -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Sun, Nov 25, 2001 at 06:27:57PM -0500, Jeremy Hansen wrote: > Has any work been done to create an option for rsync to send its logging > output to STDOUT for djb style logging? This would be a useful option for > me. --log-stdout? I'm assuming that rsync currently uses syslog(3), yes? Yes, it would be a useful option imo. Let's first see if the --no-detach option makes it in though, we can then add this other option. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Wed, Nov 21, 2001 at 03:27:52PM -0600, Dave Dykstra wrote: > I'm not familiar with daemontools; I checked the web site and it wasn't > obvious to me. What's the advantage of using daemontools supervise? Why > does it need to run the daemon as a subprocess? Like AIX's SRC (System Resource Controller), svscan/supervise together with svc/svstat are designed to control daemons in a uniform, platform-independent way. So rather than having start|stop scripts (/etc/rc?.d/*, /etc/rc.local, etc.) for each daemon, a service scanner (svscan) runs which starts supervise processes, which in turn manage each individual service. By virtue of supervise being the parent of the service being managed, problems with stale pidfiles and such are being avoided. A simple example: traitor:/service% ls -l sshd lrwxr-xr-x 1 root wheel 17 May 7 2001 sshd -> /var/service/sshd traitor:/service% ls -l /var/service/sshd total 3 drwxr-xr-x 4 nobody wheel 512 May 7 2001 log -rwxr-xr-x 1 rootwheel 91 May 7 2001 run drwx-- 2 rootwheel 512 Nov 21 13:48 supervise traitor:/service% cat /var/service/sshd/run #!/bin/sh PATH=/usr/sbin exec sshd -D -e 2>&1 The service can be controlled (up/down/restart/run once) using the svc command. Among others, one thing this setup makes easy is for a privileged process to be controlled by an unprivileged group of users, by simply manipulating the permissions on the service control socket. > Assuming it's a command to make sure a daemon keeps running, it seems to me > that it ought to be able to work if given a process id and not require any > deaemon it could supervise to be modified to not fork. I have a script for > my own use which does that. It does more than just that. Hope this explains things a little bit. > - Dave Dykstra -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote:
> Excuse me, I meant to say if stdin in IS a socket.
That mode of operation is used when running from inetd or tcpserver. Not
detaching from the parent is useful when one wants the parent (supervise in
this case) to manage the rsync process instead.
Here's a patch, based on Max Bowsher's patch. If deemed useful I will supply
the man patch as well.
Index: clientserver.c
===
RCS file: /cvsroot/rsync/clientserver.c,v
retrieving revision 1.74
diff -u -r1.74 clientserver.c
--- clientserver.c 9 Nov 2001 06:58:39 - 1.74
+++ clientserver.c 21 Nov 2001 19:26:45 -
@@ -26,6 +26,7 @@
extern int read_only;
extern int verbose;
extern int rsync_port;
+extern int no_detach;
char *auth_user;
int sanitize_paths = 0;
@@ -500,7 +501,8 @@
return start_daemon(STDIN_FILENO);
}
- become_daemon();
+ if (!no_detach)
+ become_daemon();
if (!lp_load(config_file, 1)) {
exit_cleanup(RERR_SYNTAX);
Index: options.c
===
RCS file: /cvsroot/rsync/options.c,v
retrieving revision 1.62
diff -u -r1.62 options.c
--- options.c 9 Sep 2001 04:41:14 - 1.62
+++ options.c 21 Nov 2001 19:26:46 -
@@ -55,6 +55,7 @@
int am_sender = 0;
int recurse = 0;
int am_daemon=0;
+int no_detach = 0;
int do_stats=0;
int do_progress=0;
int keep_partial=0;
@@ -203,6 +204,7 @@
rprintf(F," --include-from=FILE don't exclude patterns listed in FILE\n");
rprintf(F," --version print version number\n");
rprintf(F," --daemonrun as a rsync daemon\n");
+ rprintf(F," --no-detach do not detach from the parent\n");
rprintf(F," --address bind to the specified address\n");
rprintf(F," --config=FILE specify alternate rsyncd.conf file\n");
rprintf(F," --port=PORT specify alternate rsyncd port number\n");
@@ -285,6 +287,7 @@
/* TODO: Should this take an optional int giving the compression level? */
{"compress",'z', POPT_ARG_NONE, &do_compression},
{"daemon", 0, POPT_ARG_NONE, &am_daemon},
+ {"no-detach",0, POPT_ARG_NONE, &no_detach},
{"stats",0, POPT_ARG_NONE, &do_stats},
{"progress", 0, POPT_ARG_NONE, &do_progress},
{"partial", 0, POPT_ARG_NONE, &keep_partial},
--
Jos Backus _/ _/_/_/Santa Clara, CA
_/ _/ _/
_/ _/_/_/
_/ _/ _/_/
[EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: --no-detach option?
On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote: > Excuse me, I meant to say if stdin in IS a socket. That mode of operation is indeed useful when running rsync --daemon from inetd or tcpserver. I am talking about a mode in which rsync still listen()s, etc. but can be managed by its parent (supervise in the daemontools case). -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
--no-detach option?
How about adding a --no-detach option (to be used in combination with --daemon) to rsync so it can be run under Dan Bernstein's daemontools' supervise? If there's interest I'll provide a patch. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync 2.4.6 hangs.
On Tue, Jul 10, 2001 at 04:13:11PM -0700, Jos Backus wrote: > I'm using the same CVS server. I think my problem is that I applied your > rsync-nohang.patch first, whereas I should only be applying > rsync-nohang2.patch against the current CVS sources. Correct? To answer my own question: yes. rsync-nohang2.patch applies against CVS without problems. Thanks Wayne. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync 2.4.6 hangs.
On Tue, Jul 10, 2001 at 03:19:51PM -0700, Wayne Davison wrote: > They will apply to stock 2.4.6 with offsets (but no fuzz), if you so > desire. They were created from the CVS version, though. OK. > The nohang1 patch is already incorporated into the CVS version, so it is > the only one that should have given you trouble. I was able to apply > nohang2 to an fresh CVS version without a whimper. What CVS server are > you using? I'm using ":pserver:[EMAIL PROTECTED]:/cvsroot". I'm using the same CVS server. I think my problem is that I applied your rsync-nohang.patch first, whereas I should only be applying rsync-nohang2.patch against the current CVS sources. Correct? Thanks, -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: rsync 2.4.6 hangs.
Hi Wayne, On Tue, Jul 10, 2001 at 01:59:22PM -0700, Wayne Davison wrote: > http://www.clari.net/~wayne/rsync-nohang1.patch > http://www.clari.net/~wayne/rsync-nohang2.patch Are these to be applied against the stock 2.4.6? In particular, the second patch does not apply cleanly against yesterday's CVS. I'd like to build an up-to-date version of rsync with these patches. Thanks, -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: Anti-hang comments?
On Thu, Jul 05, 2001 at 12:48:06PM -0500, Dave Dykstra wrote: > If you really want it to stay in the foreground, edit become_daemon in > socket.c. It would be nice to have this available as an option so rsyncd can be run under djb's daemontools. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
