fix: Use CopyN to handle growing file size#43
Merged
mholt merged 1 commit intomholt:mainfrom Jun 23, 2025
Merged
Conversation
mholt
approved these changes
Jun 23, 2025
Owner
mholt
left a comment
There was a problem hiding this comment.
Oh thanks for the test case!
That's very interesting, I seem to remember this. It was patched 2 years ago in the previous repo: mholt/archiver@09bbccc
That's from the very last git blame on that repo, whereas the very first on this one shows "Initial commit" without the CopyN. So I'm not sure where it got reverted!! Weird!
Ohhhh I wonder if a linter complained at some point... 😬
If that linter pops up again we should disable it and report it as a faulty linter. Because this is definitely correct.
This file contains hidden or 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
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.
Was hitting an issue archiving a tar with a file that was growing. The comment in the code indicates that CopyN should have been used with the file info size. Not sure if there is some history here I am missing.
Added test case that reproduced the issue prior to making the fix.