On Thu, 3 Jul 2003 10:02:33 -0700
Wayne Davison <[EMAIL PROTECTED]> 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
receiver's side.
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
Yasuoka Masahiko ([EMAIL PROTECTED])
Second Software Inc. http://www.second-software.com/
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
