bug? -z option and large compressed data
yasuoka at yasuoka.net
Fri Jul 4 05:24:29 EST 2003
On Thu, 3 Jul 2003 10:02:33 -0700
Wayne Davison <wayned at samba.org> wrote:
> > In addition to, tx_strm context keeps pending output. It must be
> > flushed here.
> It seems weird to me that the code was not flushing the output, but I am
> worried that changing this will make us incompatible with older rsync
> versions (since this data affects the compressor on each side without
> actually sending any of it over the socket). I also haven't seen any
> failures using Z_INSERT_ONLY instead of Z_SYNC_FLUSH. Did you encounter
> a failure case without flushing?
Yes, I encountered in my second patch. When tx_strm.avail_out is not
enough size, deflate() returns Z_OK even if there is pending output
in tx_strm internal. If this occurs, next time send_deflated_token()
is called with "token != -2", those pending output (that was created
by Z_INSERT_ONLY) will be sent to receiver. This will make failure on
But your patch seems to have enough size to avoid this problem.
> > Please check below patch.
> I think I'd prefer a little simpler approach to fixing this. Here's a
> patch that expands the obuf to a larger size and just uses this larger
> size in this one part of the token compression code. This avoids the
> problem in your first patch where you affected too many things (by
> changing the value of MAX_DATA_COUNT) and avoids adding an extra loop
> as well. In my testing this fixed a compression failure when syncing
> a large iso.
Your patch is good and simple. This fixed all my failure cases.
Thank you very much,
Yasuoka Masahiko (yasuoka at second-software.com)
Second Software Inc. http://www.second-software.com/
More information about the rsync