allow 70gb+ files using a 4 byte marker and then 64 bit binary in nbo #53
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I had a user report failure for large single files (70gb+) created using ArchiveStream. From digging into things gnu tar is happy to make such archives and will use a marker
0x80 0x0 0x0 0x0
in nbo then the 64 bit size in binary stored in nbo in the 12 byte size field.I have only tested this patch on a few files, one with all zeros and then one which appends the Fedora linux image to itself a number of times to make a single 84gb file.
I made a very basic test script to make a tar archive from a directory which made a tar file that gnu tar was happy to view and extract
So this appears to work ok. I am of the mind that if gnu tar can extract it ok then that is the pillar that I base "works ok" on. At least for initial testing. Obviously it would be handy to track down information on if something should be changed in addition to this to indicate that the size is in binary. Also seeing if other extractors are happy to touch these generated tar files.