mirror of
https://github.com/adamhathcock/sharpcompress.git
synced 2026-02-03 21:23:38 +00:00
Does RarArchive support reading block sizes at time for large 2GB+ rar files, and unrar based block sizes ? #447
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 @jameelahmeds on GitHub (Mar 30, 2021).
Does the RarArchive support reading a user-defined number of bytes at a time from compressed file and then uncompressing bytes at time.
Is this supported ? If so which class and function to use ? any samples ?
I have a large 2GB+ rar file on Azure Blob Storage, and want to uncompress to Azure Blob storage.
Thank you
@adamhathcock commented on GitHub (Mar 31, 2021):
Well, using a RarReader you don't actually decompress or read from the underlying stream until you start reading the entry. You can't seek to a specific position in a compressed stream as the bytes for an entry is just a single stream of compressed bytes that requires the previous knowledge to continue forward.
Rar is a simple format that is
with no directory of entries. The RarArchive will scan a seekable stream for entries by skipping the compressed bytes which is fast. Of course this is only a seekable stream and won't work with a network stream from Azure Blob Storage.RarReader will skip entries but by reading the non-seekable stream bytes to a null stream til it gets to the next entry.
@marcussacana commented on GitHub (Dec 19, 2021):
@adamhathcock I don't know about the rar format, but I see the reason why he isn't seekable, that make sense.
But anyway, a idea, maybe is possible if we have the file partially already extracted resume his extraction by reading the extracted file and rebuilding the extraction dictionary to resume from the end of the partially extracted file?
it seems absurd to waste time reprocessing the file, but I'm extracting directly from the cloud, and on top of files over 90gb, if that were possible I would like to put it into practice, even if I have to study the format and formulate the strategy.
@adamhathcock commented on GitHub (Dec 20, 2021):
Your strategy can work but you have to manage the Stream of bytes yourself. Sharpcompress will take any Stream and try to decompress if there are bytes available in it.