fix: Restore Dockerfile build performance regressed by tar block factor

PR #1684 lowered the SharpZipLib block factor to 1 to drop the trailing
record padding that races Podman's archive reader, causing a broken pipe
(HTTP 500) on resource mappings (#1683). It applied this to both archive
paths, but the on-disk Dockerfile build context is written to a
FileStream, where a 512 B record forces a write and flush per block and
regresses image builds by up to 10x (worst on .NET Framework).

Only the in-memory archive streamed to the daemon (resource mappings)
needs the padding gone, and a MemoryStream pays almost nothing for the
small record size (~1.3x, benchmarked). So keep block factor 1 there and
revert the Dockerfile build context to SharpZipLib's default block
factor. Document the asymmetry so it is not "consistency-fixed" back into
a regression, and add a test asserting the streamed archive carries no
padding beyond the two end-of-archive blocks.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: HofmeisterAn

src/Testcontainers/Images/DockerfileArchive.cs

@@ -192,7 +192,7 @@ public async Task<string> Tar(CancellationToken ct = default)
 
       using (var tarOutputFileStream = new FileStream(dockerfileArchiveFilePath, FileMode.Create, FileAccess.Write))
       {
-        using (var tarOutputStream = new TarOutputStream(tarOutputFileStream, TarArchiveDefaults.TarBlockFactor, Encoding.Default))
+        using (var tarOutputStream = new TarOutputStream(tarOutputFileStream, Encoding.Default))
         {
           tarOutputStream.IsStreamOwner = false;
 

src/Testcontainers/TarArchiveDefaults.cs

@@ -9,6 +9,13 @@ internal static class TarArchiveDefaults
     // blocks while the HTTP sender is still flushing the padding, causing EPIPE
     // (HTTP 500 "broken pipe"). See:
     // https://github.com/testcontainers/testcontainers-dotnet/issues/1683.
+    //
+    // This only applies to archives we stream to the daemon over a pipe (resource
+    // mappings via a MemoryStream), where the surplus padding is both unnecessary
+    // and harmful. Do NOT reuse it for the Dockerfile build context, which is
+    // written to a FileStream on disk: a 512 B record forces a write and flush per
+    // block and regresses image builds by up to 10x. That path keeps SharpZipLib's
+    // default block factor on purpose.
     internal const int TarBlockFactor = 1;
   }
 }

tests/Testcontainers.Platform.Linux.Tests/TarOutputMemoryStreamTest.cs

@@ -59,6 +59,31 @@ public void TestFileExistsInTarFile()
         Assert.Contains(actual, file => file.EndsWith(_testFile.Name));
     }
 
+    [Fact]
+    [Trait(nameof(DockerCli.DockerPlatform), nameof(DockerCli.DockerPlatform.Linux))]
+    public void TarFileDoesNotContainPaddingBeyondEofBlocks()
+    {
+        // Given
+        _tarOutputMemoryStream.Close();
+        _tarOutputMemoryStream.Seek(0, SeekOrigin.Begin);
+
+        using var buffer = new MemoryStream();
+        _tarOutputMemoryStream.CopyTo(buffer);
+
+        var archive = buffer.ToArray();
+
+        // When
+        var length = archive.Length;
+
+        // Then
+        // The archive holds a single 1-byte file: one header block, one data block and
+        // the two end-of-archive blocks. SharpZipLib's record padding (block factor 20)
+        // would otherwise inflate it to a 10240-byte record boundary.
+        Assert.Equal(4 * TarBuffer.BlockSize, length);
+        Assert.Equal(0, length % TarBuffer.BlockSize);
+        Assert.All(archive.Skip(length - (2 * TarBuffer.BlockSize)), b => Assert.Equal(0, b));
+    }
+
     [UsedImplicitly]
     public sealed class FromResourceMapping : TarOutputMemoryStreamTest, IResourceMapping, IClassFixture<FromResourceMapping.HttpFixture>, IAsyncLifetime
     {