`ZipFile.ExtractToDirectory` causes faulty permissions with pinned files

[BaerMitUmlaut]

Description

When unpacking certain ZIP files on Linux that were packed on Windows and had the "pinned" attribute set (example file), ZipFile.ExtractToDirectory will cause the file to only have execute permissions (------x---).

Reproduction Steps

• Pick any file
• Set the "pinned" attribute through cmd: attrib +p filename
• Pack as a ZIP file using 7zip (packing through Windows does not preserve the "pinned" attribute)
• Unpack the file on Linux (or in a WSL owned folder like /tmp) using the following code:

  public class Program
  {
      private static void Main(string[] args)
      {
          ZipFile.ExtractToDirectory(args[0], args[0].Replace(".zip", ""), Encoding.UTF8);
      }
  }

• Verify the files permissions using ls -l:

  $ ls -l /tmp/dotnet
  total 28
  ------x--- 1 foobar foobar 24783 Nov  7 13:41 dotnet.jpg
  

Expected behavior

The permissions should be -rw-r--r--, like any file that did not have the "pinned" attribute set when it was packed.

Actual behavior

Read and write permissions are missing and an excutable permission is set (------x---).

Regression?

No response

Known Workarounds

Repacking the ZIP through the Windows packing tools or unsetting the "pinned" flag fixes the problem but cannot be done through code.

Configuration

• .NET 6.0
• Windows 10 / Ubuntu 20.04 in WSL

Other information

No response

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

When unpacking certain ZIP files on Linux that were packed on Windows and had the "pinned" attribute set (example file), ZipFile.ExtractToDirectory will cause the file to only have execute permissions (------x---).

Reproduction Steps

• Pick any file
• Set the "pinned" attribute through cmd: attrib +p filename
• Pack as a ZIP file using 7zip (packing through Windows does not preserve the "pinned" attribute)
• Unpack the file on Linux (or in a WSL owned folder like /tmp) using the following code:

  public class Program
  {
      private static void Main(string[] args)
      {
          ZipFile.ExtractToDirectory(args[0], args[0].Replace(".zip", ""), Encoding.UTF8);
      }
  }

• Verify the files permissions using ls -l:

  $ ls -l /tmp/dotnet
  total 28
  ------x--- 1 foobar foobar 24783 Nov  7 13:41 dotnet.jpg
  

Expected behavior

The permissions should be -rw-r--r--, like any file that did not have the "pinned" attribute set when it was packed.

Actual behavior

Read and write permissions are missing and an excutable permission is set (------x---).

Regression?

No response

Known Workarounds

Repacking the ZIP through the Windows packing tools or unsetting the "pinned" flag fixes the problem but cannot be done through code.

Configuration

• .NET 6.0
• Windows 10 / Ubuntu 20.04 in WSL

Other information

No response

Author:	BaerMitUmlaut
Assignees:	-
Labels:	area-System.IO.Compression
Milestone:	-

[gwell]

Also seeing this problem on Android when using ZipFileExtensions.ExtractToFile(ZipArchiveEntry, String).

[BaerMitUmlaut]

The fix looks fairly easy:

• The _versionMadeByPlatform field needs a public getter property:
  https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.Compression/src/System/IO/Compression/ZipArchiveEntry.cs#L22
• This condition needs an additional check for the source platform:
  https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.Compression.ZipFile/src/System/IO/Compression/ZipFileExtensions.ZipArchiveEntry.Extract.cs#L86

I tried making a fix but was so far unable to get the tools completely running including a new test file, might try again later.

[carlossanlop]

@BaerMitUmlaut thanks for trying to get a fix.

I tried making a fix but was so far unable to get the tools completely running including a new test file, might try again later.

Where were you blocked? Can we help unblock you?

I wonder if this issue is related to reparse points not being fully supported: https://learn.microsoft.com/en-us/windows/win32/fileio/reparse-points

At least one of the reparse points indicates that a file is from OneDrive.

@dotnet/area-system-io have you folks worked with these files lately?

[jozkee]

@dotnet/area-system-io have you folks worked with these files lately?

No, not really. But seems like P also means Sparse in older Windows versions https://superuser.com/questions/44812/windows-explorers-file-attribute-column-values/982721#982721.

The permissions should be -rw-r--r--, like any file that did not have the "pinned"

Are all other Windows attributes ignored when unzipping in Linux?

[BaerMitUmlaut]

Are all other Windows attributes ignored when unzipping in Linux?

I don't know, but there might be more that influence it. This one was just the one I found in the wild on a production system.