bug? -z option and large compressed data

[Yasuoka Masahiko]

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
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 (yasuoka at second-software.com)
    Second Software Inc.   http://www.second-software.com/