std.tar don't overwrite files on unpack #19081
Merged
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
Fail with error if file already exists. File is not silently overwritten but an error is raised. Fixes: ziglang#18089
Like in issue ziglang#18089, this tar contains, same file name in two case sensitive name version. Unpack should fail on case insensitive file systems and succeed on case sensitive. $ tar tvf 18089.tar 18089/ 18089/alacritty/ 18089/alacritty/darkermatrix.yml 18089/alacritty/Darkermatrix.yml
Report file name which failed to create in all cases.
Or other platform which don't support symlinks.
It was not returning error in all cases. Bug in refactoring.
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.
Don't silently overwrite files on tar unpack, return error instead.
In #18089 we are unpacking tar which has same file with different casing in name:
On case insensitive file system (windows, macOS) that results in latter overwriting former silently. Further in the process that results in different package hashes between case sensitive and case insensitive operating systems.
From #18089:
That is what this commits do.
And some improved error reporting. That case on macOS now gives:
Another case where it is possible that we get file overwrite is when we unpack with strip_components > 0. That can result in files with same path/name, when leading component is stripped, to overwrite one another.
Fixes #18089