Fix TarWriter.TarEntry exception when adding file whose Unix group owner does not exist in the system

[carlossanlop]

Fixes #81047
Addresses dotnet/sdk-container-builds#246

Users in MacOSX ARM are seeing an exception show up when executing dotnet publish. The exception shows up when the test container is created and the TarWriterWriteEntry(fileName, entryName) is called. The method is throwing when attempting to add a file whose Unix group doesn't exist in the current machine.

The root cause is that when we call the native method that retrieves a groupName using a groupId, the P/Invoke that wraps it throws an exception if the returned string is null.

WriteEntry should be able to continue writing the rest of the entry with an empty groupName if such group is not found in the current system using the groupId. In this case, the groupName field should simply be an empty string.

Added a couple of tests that create a randomly named group, create a file in disk, assigns the group as owner of the file, then deletes the group, then adds the file as an entry to the archive.

I deleted a method that was not used anywhere but in a test file. For future reference, if we need to bring it back, it should also add a new resource string with a more useful error message for when the errno is 0 and the string is null:

This affects users from .NET 7, so we will need to backport it.

        /// <summary>
        /// Gets the group name associated to the specified group ID.
        /// </summary>
        /// <param name="gid">The group ID.</param>
        /// <returns>On success, return a string with the group name. On failure, throws an IOException.</returns>
        internal static string GetGroupName(uint gid)
        {
            string? groupName = GetGroupNameInternal(gid);
            ErrorInfo error = GetLastErrorInfo();
            if (groupName == null && error.RawErrno == 0)
            {
                throw new IOException(SR.Format(SR.IO_GroupNotFound, gid));
            }
            else
            {
                throw GetIOException(error);
            }
        }

cc @baronfel @rainersigwald

[adamsitnik]

LGTM, thank you for providing the fix @carlossanlop. If you like my suggestions please apply them before merging.

[eerhardt]

LGTM. Thanks for fixing this, @carlossanlop!

[carlossanlop]

CI failures are all unrelated:

• Libraries Test Run release coreclr windows x86 Release and Libraries Test Run release coreclr windows x64 Debug

  • All seem to be networking infra problems with the exception message: No hay más extremos disponibles desde el asignador de extremos. which translates to There are no more endpoints available in the endpoint mapper.
  • I see one issue open tracking that failure, but it's a bit old: Failures in SSL Stream tests: There are no more endpoints available in the endpoint mapper. #74838
    • The affected tests are in cryptography and networking.

• Libraries Test Run release mono linux arm64 Debug

  • At least 3 Generator Roslyn tests failing with this known issue: Roslyn source generator crash on mono/linux/arm64 #81123
    • Microsoft.Extensions.Logging.Generators.Roslyn3.11.Tests
    • System.Text.Json.SourceGeneration.Roslyn4.4.Tests
    • Microsoft.Extensions.Logging.Generators.Roslyn4.0.Tests

[carlossanlop]

/backport to release/7.0

[github-actions]

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/4001696599

[danmoseley]

this is using the pattern that is prone to a famous deadlock
https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.standardoutput?view=net-7.0#remarks

it will only occur if there is a sufficiently large amount of output, so this could well be fine here, but just FYI that this is not a good pattern to use in general.

[carlossanlop]

Fixed. Better late than never: #83126