fix bugs handling unusual tarballs with directory after contents #105
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
Codecov Report
@@ Coverage Diff @@
## master #105 +/- ##
==========================================
+ Coverage 96.26% 96.29% +0.02%
==========================================
Files 4 4
Lines 643 648 +5
==========================================
+ Hits 619 624 +5
Misses 24 24
Continue to review full report at Codecov.
|
This fixes three related bugs when processing tarballs where a directory entry appears *after* some contents of that directory. This is unusual since neither command-line `tar` nor `Tar.create` will produce tarballs like this, and I only dicovered the bug when I accidentally modified `Tar.create` to emit directory entries after emiting everything inside of the directory. Each of `extract`, `tree_hash` and `rewrite` did this wrong in slightly different ways previously. Now they all (hopefully) do the right thing, and we test that they each handle a manually generated tarball with this kind of unusual ordering.
StefanKarpinski
force-pushed
the
sk/fix-directory-after-content
branch
from
37c8e83
to
d0e2838
Compare
StefanKarpinski
added a commit
that referenced
this pull request
May 4, 2021
This fixes three related bugs when processing tarballs where a directory entry appears *after* some contents of that directory. This is unusual since neither command-line `tar` nor `Tar.create` will produce tarballs like this, and I only dicovered the bug when I accidentally modified `Tar.create` to emit directory entries after emiting everything inside of the directory. Each of `extract`, `tree_hash` and `rewrite` did this wrong in slightly different ways previously. Now they all (hopefully) do the right thing, and we test that they each handle a manually generated tarball with this kind of unusual ordering. (cherry picked from commit 9316af8)
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.
This fixes three related bugs when processing tarballs where a directory entry appears after some contents of that directory. This is unusual since neither command-line
tarnorTar.createwill produce tarballs like this, and I only dicovered the bug when I accidentally modifiedTar.createto emit directory entries after emiting everything inside of the directory. Each ofextract,tree_hashandrewritedid this wrong in slightly different ways previously. Now they all (hopefully) do the right thing, and we test that they each handle a manually generated tarball with this kind of unusual ordering.