LZX blocks in file chunks

[dxva]

Hi,
any chance someone here could tell me how exactly are LZX file chunks supposed to be extracted? So far I'm able to divide a file chunk into blocks which are supposed to expand to the size of 32768 B but once those are fed into a decompressor their type happens to be read as 5 (instead of 1-3) and thus the data is considered invalid.
I understand that this may not be the best place to post this question as it's more about rolling my own solution than using wimlib but I thought I'd give it a shot. Thank you very much.

[synchronicity]

any chance someone here could tell me how exactly are LZX file chunks supposed to be extracted? So far I'm able to divide a file chunk into blocks which are supposed to expand to the size of 32768 B but once those are fed into a decompressor their type happens to be read as 5 (instead of 1-3) and thus the data is considered invalid.

Well, before debugging your LZX decompressor itself, first you'd need to verify that the correct data is being passed into it. Note that each compressed resource begins with a table of "chunk offsets". With 32768-byte chunks (the default for LZX) there will be ((fileSize + 32767) / 32768 - 1) entries in this table, and they are either 4 or 8 bytes each depending on whether the file is >= 4 GiB or not. The " - 1" is because the first entry is omitted. For reference, wimlib's code that parses the chunk table is here: https://wimlib.net/git/?p=wimlib;a=blob ... resource.c. The same data format is also used in NTFS "system compressed files", so there is also code in the ntfs-3g-system-compression plugin that handles it: https://github.com/ebiggers/ntfs-3g-sys ... pression.c. The latter version is a bit easier to read, since it doesn't handle "solid" or "pipable" resources like wimlib does.