fix for archiving long paths that have path components starting with ".." crossing the 100-character mark #54
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
…ith .. at 100-character mark his test checks very particular scenario where path component starting with ".." of a long path gets split at 100-byte mark so that ".." goes into header and gets interpreted as parent dir (and rejected) .
This is a fix for very specific scenario where a path component starting with ".." of a long path gets split at 100-byte mark so that ".." goes into header and gets interpreted as parent dir (and rejected).
|
the problems highlighted by clippy lint check seem unrelated to my changes |
|
thanks for working on this, and sending the patch here as well |
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 is backport of my patch to
tar-rs: alexcrichton/tar-rs#390The gnu tar supports arbirary path length by putting path truncated to standard 100 chars into the header and the rest is appended to contents. tar-rs validates that no path components should be exactly ".." but in this case when a component starting with ".." (for example file named "..some_file") gets truncated after 2 characters we hit this validation and can't tar such file.
I have verified that gnu tar command can handle such paths and actually puts truncated .. in the header. This pull request makes tar-rs behave the same.
See tests for repro of the issue.