mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-03 21:23:38 +00:00
SharpCompress fails to validate tar compressed using zstd #692
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SimonCahill on GitHub (Jul 14, 2025).
It's been a while since I've actively used this library, but I'd had good experiences in the past, so I decided to use it once more.
I have the following test case:
Interestingly, it fails to detect the tar header in the marked line.
The
VerifyTarHeadermethod works as expected and doesn't throw.Checking the debugger, I get the following information:
Below is a hex dump of the zst file:
Extracting the compressed data and piping into the
tarcommand yields the desired results:I'll include the files here, too. The
.binis just the.tzstrepackaged as a sanity check that thefilecommand is reporting correctly.TestCompressDirectory_ZstCompressedTar_FileInRoot.bin.txt
TestCompressDirectory_ZstCompressedTar_FileInRoot.tar.txt
TestCompressDirectory_ZstCompressedTar_FileInRoot.tzst.txt
Am I missing something, or have I stumbled on a bug?
@SimonCahill commented on GitHub (Jul 14, 2025):
This also happens with GZip-compressed archives. The test setup is virtually the same, except for the fact it uses GZip compression.
The file looks good everywhere else, but SharpCompress is (seemingly) having issues.
For completeness' sake, here's the compression code:
@SimonCahill commented on GitHub (Jul 15, 2025):
This doesn't happen when fully decompressing the stream into a
MemoryStreambefore passing toTarArchive.I'll pull the source and see if I can debug further.
@SimonCahill commented on GitHub (Jul 17, 2025):
At least with the zstd compression, I feel the base issue is the statefulness of the Zstd compression, meaning the zstDecompStream (
DecompressionStream) cannot seek.Would explain why copying it to a MemoryStream beforehand fixes the issue.
There may have to be a workaround when using zstd as the compression algo for streaming archives.
@Morilli commented on GitHub (Jul 20, 2025):
The documentation for TarArchive.Open states "Takes a seekable Stream as a source". By passing in a non-seekable stream (the DecompressionStream), you're violating that condition and things fail.
Perhaps the method should throw if the input stream isn't seekable instead of falling over with an unidentifiable error later on?