-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tar: behavior for symbolic links to directories #74214
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsUnlike Can we behave like cc @carlossanlop @dotnet/area-system-io
|
@carlossanlop did we deliberately choose to follow, and if so, what was the reason for it? |
The Edit: Corrected below. |
@carlossanlop the issue about creation of the archive. |
Oh I see. Re-reading the issue description, I made the assumption it was about extraction. Looking at the code again, extraction won't have a problem with following a symlink. The symlink will get created pointing at a destination, regardless if it exists or not. We can fix for archive creation. |
Fixing this would require implementing the logic proposed in #52666 Due to the amount of work and the API proposal dependency, this won't make it to 7.0, so I'll move it to 8.0. We may have to also fix this in |
It should be possible to implement this using RecursePredicate or ShouldRecurseIntoEntry. If this is pushed to 8.0 it will be a breaking change. |
OK let me try. |
/backport to release/7.0-rc1 |
Unlike
tar
, currently these links are being followed.If the file linked to is in the archive it will be duplicated. If it is outside the archived directory it will be included as if it were.
Symbolic links to directories can also cause loops which will cause the archive creation to hang.
Can we behave like
tar
and not follow symlinks by default?tar
does provide an option to follow the links (--dereference
).cc @carlossanlop @dotnet/area-system-io
The text was updated successfully, but these errors were encountered: