Tar: behavior for symbolic links to directories

[tmds]

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

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
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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

Author:	tmds
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[jozkee]

@carlossanlop did we deliberately choose to follow, and if so, what was the reason for it?

[carlossanlop]

The TarFile.ExtractToDirectory TarFile.CreateFromDirectory methods should treat symlinks without following them. I'll submit a fix.

Edit: Corrected below.

[tmds]

@carlossanlop the issue about creation of the archive.

[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.

[carlossanlop]

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 ZipFile.CreateFromDirectory: https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.Compression.ZipFile/src/System/IO/Compression/ZipFile.Create.cs#L378

[tmds]

It should be possible to implement this using RecursePredicate or ShouldRecurseIntoEntry.

If this is pushed to 8.0 it will be a breaking change.