TarEntry does not support absolute paths #338
Labels
enhancement
Feature request or other improvements of existing functionality
tar
Related to TAR file format
Comments
iUnknwn
added a commit
to iUnknwn/SharpZipLib
that referenced
this issue
Apr 13, 2019
For icsharpcode#337: removes the changes to path based on current working directory. This prevents issues where files that are below the current working directly will behave differently than those that aren't. For icsharpcode#338: Simply removes the code that would remove leading forward slashes from paths. This should unbreak absolute POSIX paths, and avoid the issue where RootPath wouldn't work, though it does allow unc paths (which were previously blocked) as a potential side effect. Part of the issue with icsharpcode#338 is any changes to the path, as part of the TarEntry's GetFileTarHeader have the potential to break RootPath, so you can't simply check for UNC path names there and modify.
iUnknwn
added a commit
to iUnknwn/SharpZipLib
that referenced
this issue
Oct 31, 2019
For icsharpcode#337: removes the changes to path based on current working directory. This prevents issues where files that are below the current working directly will behave differently than those that aren't. For icsharpcode#338: Simply removes the code that would remove leading forward slashes from paths. This should unbreak absolute POSIX paths, and avoid the issue where RootPath wouldn't work, though it does allow unc paths (which were previously blocked) as a potential side effect. Part of the issue with icsharpcode#338 is any changes to the path, as part of the TarEntry's GetFileTarHeader have the potential to break RootPath, so you can't simply check for UNC path names there and modify.
|
Couldn't you just set the |
|
This is probably a duplicate of #38 (how fitting). But that one only contains dead links and not a clear description. Closing it in favor of this one. |
piksel
changed the title
piksel
added
the
enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, TarEntry.cs, in
GetFileTarHeader, trims all leading forward slashes.Trying to write
/home/username/foo.txtas an entry would to writehome/username/foo.txtThis prevents writing absolute paths to the archive, and also breaks the RootPath string, as the entry name will no longer have the root path as a sub string (if it was set to /home/username), so it will never match when the entry is added to the archive.
If we're trying to specifically avoid UNC path names, it might be easier to just test for a leading double back slash in the original path (instead of testing for leading slashes).
Expected behavior
RootPath should work as expected when adding absolute paths on POSIX.
Actual behavior
RootPath does not work as expected - file strings will never match RootPath because RootPath will still contain the leading '/', but the file entry will not.
Additionally, absolute file paths will be broken, regardless if root path is used.
Version of SharpZipLib
1.1.0
Obtained from (only keep the relevant lines)
The text was updated successfully, but these errors were encountered: