[cifs-protocol] Re: LZ77 + DIRECT2 compression MS-OXCRPC

Matthieu Suiche msuiche at gmail.com
Fri Aug 29 17:22:07 GMT 2008

I've noticed this change during my implementation of the compression
function. Without it I wouldn't be able to get a correct output. This
part is successfuly implemented in my code. The problem looks related
to the way MSFT is looking for a match window. It stops too early.

I don't know if its a volontary code optimization, or not. As I said,
I my implementation find a longer match than MSFT. Thus, my compressed
buffer is smaller than MSFT's one. And this compressed buffer is
successfuly decompressed my decompression function.

I mean my output is correct, but I want to have exactly the same
output as MSFT. That's why I've to understand the exact behavior of
the part of the function that should return the longest match.

On Fri, Aug 29, 2008 at 6:24 PM, Tom Devey <Tom.Devey at microsoft.com> wrote:
> Matthieu,
> Let me dig into this.  Also note there is a problem in the current documentation for [MS-OXCRPC] Match Length for decoding.
> The feedback to the resolution was posted below:
> <forum source="http://forums.msdn.microsoft.com/en-US/os_exchangeprotocols/thread/b4e16062-0ecf-40fa-879a-380bfbac0028">
> The [MS-OXCRPC] document says that if the match length is greater than 9 then we have to read an additional byte and use high-order nibble as an additive length. The low-order nibble should be kept and used when the next time the match length is greater than nine. As it turned out we should do quite opposite: use LOW-order nibble the first time and HIGH-order nibble the next time.
> </forum>
Matthieu Suiche

More information about the cifs-protocol mailing list