Expose reparse point tags

[iSazonov]

On Windows if we enumerating file system we should take into account reparse points and reparse point tags too - that is symbolic links, OneDrive and AppX.
For example, attempting to read OneDrive reparse point causes an unwanted file download from the Internet. AppX reparse point would be considered like symbolic link. (It seems the last does not taken into account in Directory.Delete())

FileSystemEntry exposes FileAttributes there we can check reparse point flag. But we don't have reparse point tags.
FileSystem also exposes only FileAttributes without reparse point tags.

The request comes from PowerShell Core repo. I am trying to utilize new FileSystemEnumerable and have to use extra P/Invoke to get reparse point tags.
It will be great to have reparse point tags in FileSystemEntry and FileSystem types or another way to work with the scenarios in a Core standard way.

/cc @JeremyKuhne

[JeremyKuhne]

I agree that it would be nice to have this, the trick is that we haven't fully rationalized how we want to expose platform specific data. As this impacts OneDrive scenarios as mentioned we should try and answer this in 5.0 if we can.

[iSazonov]

@JeremyKuhne PowerShell 7.0 was released yesterday and I hope in next PowerShell milestone we will address OneDrive experience - this helps to understand how .Net Core could be enhanced.

[hamarb123]

@carlossanlop I've implemented this myself in my own project for symlinks and directory junctions on Windows. I'd be happy to help with any of the following code relating to reparse points (not sure which other issues this is related to).
I have code for:

• Symlink target getting on Mac using /usr/bin/readlink (probably not the preferred method)
• Symlink target writing on Mac using /bin/ln (probably not the preferred method)
• Determining which type of reparse point a file is (except hard links) ie. None, Symlink file, Symlink Directory, Directory Junction
• Creating symbolic links on Windows using Kernel32 methods
• Getting symlink target on Windows using Kernel32 methods
• Creating directory junctions on Windows using Kernel32 methods
• Checking if a directory is a junction on Windows using Kernel32 methods
• Getting a directory junction's target on Windows using Kernel32 methods

None of my code checks hard links properly as I've not looked into them.
Edit: Looks like readlink and ln (using symlink) can be done with libc calls.

[carlossanlop]

The conversation was growing in #24271, so I requested to move it here.

There's interest in having a boolean IsLink property in FileSystemInfo to let the user now if the current file is a link. I think the information would be insufficient, because there are multiple types of links.

@jozkee and I would prefer to have an enum that lists all the reparse tags. We initially described it in the second proposal, but we decided not to propose it in the API review meeting because there wasn't enough consensus.

+   public enum ReparseTag
+   {
+       None = -1,                // Default, indicates the file is not a Reparse Point (zero is already reserved)
+       MountPoint = 0xA0000003,  // Maps to IO_REPARSE_TAG_MOUNT_POINT, describes a Junction
+       Symlink = 0xA000000C,     // Maps to IO_REPARSE_TAG_SYMLINK, the only value used by Unix
+       AppExecLink = 0x8000001B, // Maps to IO_REPARSE_TAG_APPEXECLINK
+   }

    public abstract partial class FileSystemInfo
    {
+       public ReparseTag ReparseTag { get; }
    }

We now have more information that confirms this proposal makes more sense:

• Some filesystems (those used in Unix) only have one type of link: symbolic link.
• NTFS has multiple types of links. One of them is symbolic link, but there are also junctions, AppExecLink, and others, which are known as Reparse Tags (spec).
• Filesystems are independent of the OS, meaning that an NTFS drive can be properly supported in Linux if the proper driver is installed (for example, ntfs-3g supports reparse tags).
• We need to try to keep in mind future expansions, and an enum would be a great way to ensure we clearly describe the type of link the user is handling, and can be expanded.
• We don't need to initially add all the reparse tag values to the enum, but the enum values can represent the unique hex values of the reparse tags. This way, if the user encounters an enum currently not listed (like IO_REPARSE_TAG_IIS_CACHE), and queries the ReparseTag property, they would get the value 0xA0000010, which is outside the enum range, but it's a valid value.
• The name ReparseTag is not really Windows-specific, it's NTFS-specific, but would be consistent with the FileAttributes.ReparsePoint value we already have, which represents a symbolic link in Unix.

@hamarb123 thank you for your offer to help. Sorry I didn't reply earlier. Let's first discuss what the proper course of action is, and then we can decide how we will implement it.