You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
LZIP is an LZMA-based stream format, used in conjunction with things like tar for archives.
(My own interest is in the IANA time zone distribution; a new format uses LZIP.)
I've looked at the LZMA support in SharpCompress and I don't think I can just use it out of the box - mostly due to how the dictionary size is specified. It's entirely possible that I've missed something, however.
I'd be happy to start working on a pull request if this sounds like something you'd welcome - but I'll wait for confirmation that it's actually sensible before doing so.
(I'm not sure whether it would be easy to write an lzip compressor - that's not something I personally need. I quite understand if you'd rather not support decompression without compression though.)
The text was updated successfully, but these errors were encountered:
This is definitely something to include if you need it..
Looks like you'll need a LZipReader as it's a forward-only format. It does look like you'll need to make something custom for the compression using LZMA as a base. I'm not an expert in this stuff so I'm not sure how much help I'll be if you can't get it working :)
It's fine just to do the decompression. I can probably backfill a compressor if there's demand based on what you create.
Righto. Will prototype something in order to get any idea of whether it's even feasible without actually understanding the compression deeply. If that goes well, I'll start working it into a proper PR. Thanks for the quick response :)
LZIP is an LZMA-based stream format, used in conjunction with things like tar for archives.
(My own interest is in the IANA time zone distribution; a new format uses LZIP.)
I've looked at the LZMA support in SharpCompress and I don't think I can just use it out of the box - mostly due to how the dictionary size is specified. It's entirely possible that I've missed something, however.
The file format is documented here.
I'd be happy to start working on a pull request if this sounds like something you'd welcome - but I'll wait for confirmation that it's actually sensible before doing so.
(I'm not sure whether it would be easy to write an lzip compressor - that's not something I personally need. I quite understand if you'd rather not support decompression without compression though.)
The text was updated successfully, but these errors were encountered: