Skip to content
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

[release/7.0] Disallow TarWriter from writing link entries without LinkName set #74939

Merged
merged 5 commits into from
Sep 2, 2022

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 1, 2022

Backport of #74892 to release/7.0

/cc @carlossanlop

Customer Impact

If we create an archive with TarWriter, we should only allow inserting symlink/hardlink entries that have non-null and non-empty LinkName strings. Otherwise we cannot extract them using TarFile due to having an invalid link target. This is consistent with the mklink and ln commands, which do not allow creating links with empty targets.

Testing

Added many tests to verify that TarWriter does not allow inserting symlink/hardlink entries with empty LinkName. Adjusted some existing ones as well.

Risk

Low. New feature in 7.0. Making it more robust.

IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

@carlossanlop
Copy link
Member

No tar test failures in the CI.

@danmoseley
Copy link
Member

Approved, as mentioned on original PR, under completing 7.0 scenarios. But this one is marginal -- it seems relatively low impact, and can be fixed in 8.0. So I don't think we'd take a change like this next week.

@carlossanlop carlossanlop merged commit 4a03353 into release/7.0 Sep 2, 2022
@carlossanlop carlossanlop deleted the backport/pr-74892-to-release/7.0 branch September 2, 2022 15:56
@carlossanlop
Copy link
Member

FYI I investigated all the test failures. They are all known false positives that coreeng told me are being caused by the Helix infrastructure being overstressed. The tests have no failures/errors, yet the process seems to be returning a failure value.

Example of the output:

=== TEST EXECUTION SUMMARY ===
   System.Linq.Expressions.Tests  Total: 35260, Errors: 0, Failed: 0, Skipped: 0, Time: 25.055s

@ghost ghost locked as resolved and limited conversation to collaborators Oct 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants