I'm uploading lz4 compressed files to our server, and when I am attempting to read them the stream has a very monstrous buffer that is not even remotely close to the size of the uncompressed file. We're on .NET 3.5, using C# for the code, so I had to tweak the Lz4DecoderStream.cs in order to have it work none of which should have affected the overall performance of the file, as all I changed was the generic vars to the appropriate variable type, and removed the optional setting for the inputs from long.maxlength, to requiring a size.
When I'm checking to detect if the lz4 file is appropriate, I do the following:
try
{
byte[] buffer = new byte[12];
//Gather the header information.
int intRead = st.Read(buffer, 0, 12);
//Check if we have the magic number. Currently the value (in little endian) is 0x184D2204
if (buffer[3] == 0x18 && buffer[2] == 0x4D && buffer[1] == 0x22 && buffer[0] == 0x04)
{
using (Lz4.Lz4DecoderStream lzStream = new Lz4.Lz4DecoderStream(st, 14000))
{
DownloadCapture(szFileName, szConfig, dtFile, szZip, szExt, szDownload, bSort, lzStream, output);
}
}
}
The stream st is a memorystream of the data pulled from the database. Instead of the expected 14000 size buffer, I'm obtaining a 65664 sized buffer, where the first 65535 values are zero, before it actually starts at the position that the memorystream was left at intentionally. Interestingly, it starts right after the number set within the initialization of the DecBufMask value, but I'm having a difficult time following the Lz4DecoderStream code.
If someone could be so kind as to clarify why the lz4DecoderStream is so bloated, and a better solution, it would be greatly appreciated.
Cody