TarWriter on Windows Server treats File Deduplication reparse point flag as symbolic links

[billfreist]

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.Windows.cs

Line 25 in 9fd3ece

if ((attributes & FileAttributes.ReparsePoint) != 0)

As seen in the snippet above, the Tar Entry gets mistaken for a symlink if the reparse point flag is set, but it doesn't verify if the file/directory is actually a symlink/junction. Windows Server with file deduplication enabled, or even OneDrive synced files, can set the Reparse point flag, but utilizes entirely different reparse tags.

IO_REPARSE_TAG_DEDUP is used for deduplication, whereas IO_REPARSE_TAG_MOUNT_POINT & IO_REPARSE_TAG_SYMLINK are used for junctions and symlinks.

[ghost]

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

Issue Details

---

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.Windows.cs

Line 25 in 9fd3ece

if ((attributes & FileAttributes.ReparsePoint) != 0)

As seen in the snippet above, the Tar Entry gets mistaken for a symlink if the reparse point flag is set, but it doesn't verify if the file/directory is actually a symlink/junction. Windows Server with file deduplication enabled, or even OneDrive synced files, can set the Reparse point flag, but utilizes entirely different reparse tags.

IO_REPARSE_TAG_DEDUP is used for deduplication, whereas IO_REPARSE_TAG_MOUNT_POINT & IO_REPARSE_TAG_SYMLINK are used for junctions and symlinks.

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

[billfreist]

I should note, this results in the following exception:

System.ArgumentException: The value cannot be an empty string. (Parameter 'value')
   at System.ArgumentException.ThrowNullOrEmptyException(String argument, String paramName)
   at System.Formats.Tar.TarEntry.set_LinkName(String value)
   at System.Formats.Tar.TarWriter.ConstructEntryForWriting(String fullPath, String entryName, FileOptions fileOptions)
   at System.Formats.Tar.TarWriter.ReadFileFromDiskAndWriteToArchiveStreamAsEntryAsync(String fullPath, String entryName, CancellationToken cancellationToken)

[billfreist]

Looking further, it appears this line is masking the issue (which ultimately leads to the exception due to the fallback to passing string.Empty.

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarWriter.Windows.cs

Line 61 in 9fd3ece

entry.LinkName = info.LinkTarget ?? string.Empty;

FileSystemInfo.LinkTarget checks for those proper Reparse Tags mentioned above and returns null when it doesn't have those tags. It would seem that the code could just check for the existence of that valid LinkTarget once it determines it has the reparse point file flag. Something like:

if ((attributes & FileAttributes.ReparsePoint) != 0 && info.LinkTarget is not null)

[carlossanlop]

@jozkee @adamsitnik is this something that the System.IO APIs do correctly, or do we have to address this problem in both the Tar APIs and the IO APIs? (maybe Zip too?)

[jozkee]

LinkTarget works properly.

FileSystemInfo.LinkTarget checks for those proper Reparse Tags mentioned above and returns null

[billfreist]

LinkTarget works properly.

FileSystemInfo.LinkTarget checks for those proper Reparse Tags mentioned above and returns null

Sorry, the wording wasn't clear. I meant that it returns null when its supposed to. So in the case I'm hitting with the dedup tag, its null, when it has the symbolic link or junction tags then it returns a valid link target.

[carlossanlop]

@billfreist -

I see what you mean. We should explicitly confirm that the file is a reparse point of type junction, and nothing else, and if the answer is "junction", we should store it in the archive as a symbolic link (because it's the closest entry type to junction, and because the Tar spec does not officially support junctions).

I am unsure how the other reparse points should be treated. I suspect we could try treating them as regular files. I'd have to investigate.

If it's helpful for you, @billfreist , the workaround would be to manually extract that reparse point junction entry manually, using TarArchive to open the archive, then iterating the entries until the one that failed is found, and manually creating a symbolic link for it: https://learn.microsoft.com/en-us/dotnet/api/system.io.file.createsymboliclink?view=net-7.0

[carlossanlop]

Ok I have a fix that would specifically check, just like we do in FileSystem.Windows.cs, that if we have a reparse point, we only treat it as a tar symlink if windows categorized it as a junction or as a symlink.