Implement Tar Global Extended Attributes API changes

[carlossanlop]

Addresses the rest of the APIs approved in: #69935

The other half of the APIs got merged here: #70325

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Addresses the rest of the APIs approved in: #69935

Depends on the conversion constructors PR: #70325

While I merge that other PR, this one can be reviewed by looking at the 3 individual commits (look at that pretty separator commit 🙂):

Author:	carlossanlop
Assignees:	carlossanlop
Labels:	area-System.IO
Milestone:	7.0.0

[carlossanlop]

Force pushing a rebase merge to fix merge conflicts with main.

[carlossanlop]

/azp run runtime-extra-platforms

[carlossanlop]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[danmoseley]

As an aside - the code below reading TMPDIR then falling back to /tmp- why doesn't it just call Path.GetTempPath() that does the same thing?

[carlossanlop]

Good suggestion. I'll use Path.GetTempPath.

Here's why I wasn't using that:

The GNU tar manual specifies how the global extended attribute header name field obtains its value:

8.3.7.1 Controlling Extended Header Keywords

$TMPDIR/GlobalHead.%p.%n

[...] $TMPDIR stands for the value of the TMPDIR environment variable. If TMPDIR is not set, tar uses /tmp.

This description looks very similar to the remarks section of Path.GetTempPath:

Remarks

This method checks for the existence of environment variables in the following order and uses the first path found:

Linux

1. The path specified by the TMPDIR environment variable. If the path is not specified in the TMPDIR environment variable, the default path /tmp/ is used.

Windows

1. The path specified by the TMP environment variable.
2. The path specified by the TEMP environment variable.
3. The path specified by the USERPROFILE environment variable.
4. The Windows directory.

So a couple of things need to be considered if we are to use Path.GetTempPath:

• I don't see why any tool would be reading the GEA path, or having reading/writing behavior depend on it. The field isn't very interesting, unless the user cares about the process ID or the sequence number.
• Keep in mind that none of the tar specs (at least the ones I read) specify what the expected behavior for Windows should be. Everything is Unix focused. If we format that string embedding Windows paths, I hope other tools don't break due to finding unexpected drive names or \ separators in that field. But go back to the previous point: I don't think any tool should make its behavior depend on this field.
• If the Windows path ends up being larger than than 100 bytes, the sequence number and process ID would get truncated. Which is fine, I guess, because a couple of lines below, I re-generate the string by forcing the usage of /tmp.

[adamsitnik]

Overall LGTM, the only thing I would like to know before hitting the accept button is why the code is using the TMPDIR env var rather that calling the Path API? (issue initally raised by Dan)

[adamsitnik]

nit: it's hard to verify the long string lengths, perhaps you could use the string ctor that accepts char count and just repeat a single char? Example:

- "00000000001111111111222222222233333333334444444444555555555566666666667777777777888888888899999999/"
+ new string('0', 98) + "/"

[carlossanlop]

There are two reasons for these long strings:

1. The tar assets from dotnet/runtime-assets already use these strings for long directory names and filenames, so changing these would mean changing the assets first, then bump the package version number in this PR.
2. When I was starting to test long names, I discovered it was very annoying to not be able to determine where exactly the string was getting unexpectedly truncated, or causing a failure. Having groups of 10 equal characters made it much easier to track the exact location.

[carlossanlop]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[carlossanlop]

The runtime-extra-platforms job may hit either timestamp related failures or long path related failures. Both are being fixed in other PRs:

#71038 (timestamps)

#71115 (long paths)

[adamsitnik]

LGTM, thank you @carlossanlop !