Proposed API for symbolic links

[carlreinke]

Edit by @carlossanlop: Revisited API Proposal

---

---

Original proposal:

Rationale

The ability to interact with symbolic links (symlinks) in .NET is currently limited to determining that a file is ReparsePoint. This proposed API provides the ability to identify, read, and create symbolic links.

Proposed API

public class Directory
{
    public static DirectoryInfo CreateSymbolicLink(string linkPath, string targetPath);
    public static string GetSymbolicLinkTargetPath(string linkPath);
    public static bool IsSymbolicLink(string path);
}

public class File
{
    public static FileInfo CreateSymbolicLink(string linkPath, string targetPath);
    public static string GetSymbolicLinkTargetPath(string linkPath);
    public static bool IsSymbolicLink(string path);
}

public class FileSystemInfo
{
    public bool IsSymbolicLink { get; }
    public string SymbolicLinkTargetPath { get; }

    public void CreateSymbolicLink(string linkPath);
}

Details

The path returned from GetSymbolicLinkTargetPath(string)/SymbolicLinkTargetPath will be returned exactly as it is stored in the symbolic link. It may reference a non-existent file or directory.

For the purposes of this API, NTFS Junction Points are considered to be like Linux bind mounts and are not considered to be symbolic links.

Updates

• Move GetSymbolicLinkTargetPath and IsSymbolicLink from Path to Directory, DirectoryInfo, File and FileInfo.
• Add CreateSymbolicLink.
• Split from dotnet/runtime#23871.
• Change path to linkPath where a link file's path is desired.
• Move the APIs to the FileSystemInfo base class.

[hamarb123]

Please check my comment in https://github.com/dotnet/runtime/issues/1908#issuecomment-852440826.

[iSazonov]

Thinking more about approved (https://github.com/dotnet/runtime/issues/24271#issuecomment-849816518) API I am sure it will work well in PowerShell.

We need to make a conclusion about implementation of target resolving since ReparsePointTag list is open and new tags can be introduced:

• do we want configurable solution?
• or we can accept locked implementation like PowerShell IsReparsePointLikeSymlink()? If new RPT will be added can we get a fix in servicing?

[joshudson]

So this doesn't trouble me anymore; I will be content to carry around my own static file provider as long as necessary; however a good test for your own symbolic link API would be fixing this: https://github.com/dotnet/aspnetcore/issues/2774 ; the bug is due to calling new FileInfo() and getting back a length of 0 and not serving any data; should be a trivial fix if your symbolic link API is right.