Handle 0byte .pars gracefully #17
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
.Add throws an error if it's the top-level par, because then it can't infer whether to IncludeDots. .Add tolerates zero-length pars inside the top-level par. .Extract and .List warn the user if the top-level par is zero-length, but otherwise permit it. This includes creating empty directories when extracting zero-length PARs recursively. I haven't added command-line flags to change this behaviour, because any error that gets thrown inside Add, Extract, or List on encountering a 0B .par won't have enough information to help the user. I don't think the ParArchiveReader can throw an error including the filepath the BinarySource came from, so any error would just indicate "somewhere inside this .par there's an 0b file" and that's not useful.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As discovered in #16 ParTool throws EndOfStreamException when opening 0b pars. Because these pars appear in the wild, I thought it would be best to handle them gracefully.
This changes the behaviour of four commands.
Addthrows an error if it's the top-level par, because then it can't infer whether to IncludeDots.Addtolerates zero-length pars inside the top-level par, treating them as a par with no files inside.ExtractandListwarn the user if the top-level par is zero-length, but otherwise treat them as a par with no files inside.This includes creating empty directories when recursively extracting zero-length PARs inside the top-level par.
Removetolerates zero-length pars anywhere.I haven't added command-line flags to change this behaviour, because any error that gets thrown inside Add, Extract, List, or Remove on encountering a 0B .par won't have enough information to help the user.
I don't think the ParArchiveReader can throw an error including the filepath the BinarySource came from, so any error would just indicate "somewhere inside this .par there's an 0b file" and that's not useful.
Includes unit tests for ParArchiveReader in various 0b scenarios.
This adds an AllowZeroLengthPars parameter to ParArchiveReaderParameters, which all usages override to true. I'm open to removing the parameter and making the only behaviour to allow them, if requested.