I'm sorry, but I don't have any familiarity with that part of rsync code
and don't have any ideas for you.
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.
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.
- Dave
On Tue, Jan 29, 2002 at 06:20:07PM -0800, Jos Backus wrote:
> 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 staff 512 Jan 17 15:08 s
> -rwxr-xr-x 1 jos staff 455 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 rsync GIO fd 6 wrote 34 bytes
> "\^^\0\0\binflate returned -3 (0 bytes)
> "
> 52358 rsync RET write 34/0x22
> 52358 rsync CALL sigaction(0x1e,0xbfbfe770,0xbfbfe758)
> 52358 rsync RET sigaction 0
> 52358 rsync CALL sigaction(0x1f,0xbfbfe760,0xbfbfe748)
> 52358 rsync RET sigaction 0
> 52358 rsync CALL unlink(0xbfbfed38)
> 52358 rsync NAMI ".f2.8ENkb7"
> 52358 rsync RET unlink 0
> 52358 rsync CALL write(0x6,0x807b180,0x4f)
> 52358 rsync GIO 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;
