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 <[EMAIL PROTECTED]> wrote: > Matthieu, > > Let me dig into this. Also note there is a problem in the current > documentation for [MS-OXCRPC] 3.1.7.2.2.4 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 _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
