Exception not thrown for ZipFile inside Blazor-Server Service

[BuchholzTim]

Description

Creating an archive of a folder (in blazor), which contains a named pipe in DotNet 6.0 via the ZipFile Class causes the program to block indefinitely long, without any kind of exception thrown.

1. Create a Named Pipe in a Linux distribution with mkfifo (for me this happened while running my dotnet application inside a docker conatiner)
2. Try to compress the directory containing the named pipe with ZipFile.CreateFromDirectory inside a Blazor-Server Service

Configuration

• .NETCore 6.0.0
• Hosted Blazor Webassembly (dotnet new blazorwasm -ho)

Other information

An Exception is thrown when I try to ZIP the same directory inside a simple Dotnet Console Application.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

Description

Creating an archive of a folder (in blazor), which contains a named pipe in DotNet 6.0 via the ZipFile Class causes the program to block indefinitely long, without any kind of exception thrown.

1. Create a Named Pipe in a Linux distribution with mkfifo (for me this happened while running my dotnet application inside a docker conatiner)
2. Try to compress the directory containing the named pipe with ZipFile.CreateFromDirectory inside a Blazor-Server Service

Configuration

• .NETCore 6.0.0
• Hosted Blazor Webassembly (dotnet new blazorwasm -ho)

Other information

An Exception is thrown when I try to ZIP the same directory inside a simple Dotnet Console Application.

Author:	BuchholzTim
Assignees:	-
Labels:	area-System.IO.Compression, untriaged
Milestone:	-

[adamsitnik]

Hi @BuchholzTim

Are you sure that you are using mkfifo correctly? It's quite easy to get blocked using it.

Accodring to mkfifo man page:

Opening a FIFO for reading normally blocks
until some other process opens the same FIFO for writing, and
vice versa.

Moreover, the reading is finished when writer closes the file descriptor.

[adamsitnik]

An Exception is thrown when I try to ZIP the same directory inside a simple Dotnet Console Application.

I've tried to repro that, but I've failed. Here is the code that I've used:

public async Task CanZipNamedPipe()
{
    string destPath = Path.Combine(TestDirectory, "dest.zip");

    string subFolderPath = Path.Combine(TestDirectory, "subfolder");
    string fifoPath = Path.Combine(subFolderPath, "namedPipe");
    Directory.CreateDirectory(subFolderPath); // mandatory before calling mkfifo
    Assert.Equal(0, mkfifo(fifoPath, 438 /* 666 in octal */));

    byte[] contentBytes = { 1, 2, 3, 4, 5 };

    await Task.WhenAll(
        Task.Run(() =>
        {
            using FileStream fs = new (fifoPath, FileMode.Open, FileAccess.Write, FileShare.Read);
            foreach (byte content in contentBytes)
            {
                fs.WriteByte(content);
            }
        }),
        Task.Run(() =>
        {
            ZipFile.CreateFromDirectory(subFolderPath, destPath);

            using ZipArchive zippedFolder = ZipFile.OpenRead(destPath);
            using Stream unzippedPipe = zippedFolder.Entries.Single().Open();

            byte[] readBytes = new byte[contentBytes.Length];
            Assert.Equal(contentBytes.Length, unzippedPipe.Read(readBytes));
            Assert.Equal<byte>(contentBytes, readBytes);
            Assert.Equal(0, unzippedPipe.Read(readBytes)); // EOF
        }));
}

[DllImport("libc", SetLastError = true)]
private static extern int mkfifo(string path, int mode);

@BuchholzTim Could you please share more details (repro, stack trace)?

[ghost]

This issue has been marked needs more info since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

[ghost]

This issue has been automatically marked no recent activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no recent activity.

[ghost]

This issue will now be closed since it had been marked no recent activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.