[NETSDKE2E][VMR].NET 10 Preview 4 Binaries could not work normally on Alpine Linux.

[NicoleWang001]

Describe the bug

.NET 10 Preview 4 Binaries could not work normally on Alpine Linux.

To Reproduce

On Alpine Linux, try to manually install runtime, aspnetcore-runtime and SDK by Binaries from VMR build

Exceptions (if any)

The un-tared files are normally
Runtime binary

Aspnetcore-runtime binary

SDK binary

Note:

1. This issue is also reproduced on Alpine Linux Arm64 and Arm32
2. This issue is not reproduced on regular builds

[jkoritzinsky]

I can't repro this with 10.0.100-preview.4.25214.102 or 10.0.100-preview.4.25214.103 with the Alpine Linux x64 artifacts from Unified Build on an Alpine Linux 3.21 or 3.20 docker image.

[mmitche]

The tar appears to be somewhat corrupted. The files that would make up the SDK appear in two separate directories. E.g.

Most of the SDK appears under 0000000/./. Some of the rest appears under ./. This causes obvious failures. It's unclear why the asset comparison does not see this issue. Maybe different archive handling on different platforms? Either way, need to get to the bottom of it.

[mmitche]

I've handed this off to @carlossanlop for investigation. It is an issue with the tar rewriting. The following code below will generate a bad output archive iun some cases.:

using System.IO;
using System.IO.Compression;
using System.Formats.Tar;

string inputFile = args[0];
string outputFile = args[1];

using MemoryStream streamToCompress = new();
using (TarWriter writer = new(streamToCompress, leaveOpen: true))
{
    foreach (TarEntry entry in ReadTarGZipEntries(inputFile))
    {
        writer.WriteEntry(entry);
    }
}

streamToCompress.Flush();

streamToCompress.Position = 0;
using (FileStream outputStream = File.Open(outputFile, FileMode.Create, FileAccess.Write))
{
    using GZipStream compressor = new(outputStream, CompressionMode.Compress);
    streamToCompress.CopyTo(compressor);
}

static IEnumerable<TarEntry> ReadTarGZipEntries(string path)
{
    using FileStream streamToDecompress = File.OpenRead(path);
    using GZipStream decompressor = new(streamToDecompress, CompressionMode.Decompress);
    using TarReader tarReader = new(decompressor);
    while (tarReader.GetNextEntry() is TarEntry entry)
    {
        yield return entry;
    }
}

[carlossanlop]

I have a workaround. Instead of saving the entry directly as a GNU formatted entry:

    foreach (TarEntry entry in ReadTarGZipEntries(inputFile))
    {
        writer.WriteEntry(entry);
    }

Force the entry to write to be converted to the PAX format by using the constructor for entry conversion:

    foreach (TarEntry entry in ReadTarGZipEntries(inputFile))
    {
        writer.WriteEntry(new PaxTarEntry(entry));
    }

Now both the input and the output, using your shared repro, look exactly the same (everything inside the compressed file shows up under the . folder, instead of the weird 00000000000 folder). See the screenshot below (my fixed output in the back, the original input on the front).

The PAX format has no field length restrictions of any kind. It is the most flexible of the formats, unlike the GNU format.

I do think there's a bug in the way we're handling GNU, and I'll investigate it, but meanwhile this workaround should unblock you.

[mmitche]

THanks!!!

[lewing]

I think the issue is you want to construct the TarWriter with the same Format as the entries you use. So reading the first entry then constructing the writer from the header format there.

[carlossanlop]

Is there a specific reason why you need a GNU entry specifically? They're all part of the spec. Any tar tool should be able to read all formats.

[lewing]

I think the issue is mixing types in a single file, Nikola was getting error from (debian) tar on real files using this workaround.

corrupted filesystem tarfile in package archive: unsupported PAX tar header type 'x'

[lbussell]

Just confirming that this affects more than just linux-musl .tar.gz archives - alpine docker images fail to build, but the non-alpine platforms are failing SDK content comparison tests:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=1020009&view=logs&j=d76ba96f-fb0b-5ca5-17e1-8a08cdb4af9f&t=34b5c17c-4f0c-5ac1-136f-37af5de223af&l=196

[carlossanlop]

Understood. I'll prioritize a fix.