API Proposal: tell if a filesystem entry is any type of link #53577
Comments
carlossanlop
added
the
api-suggestion
dotnet-issue-labeler
bot
added
area-System.IO
untriaged
|
Tagging subscribers to this area: @carlossanlop Issue DetailsBackground and MotivationWe recently got some APIs approved to provide the ability to create a symbolic link, and to return the target of a symbolic link. The discussion continued after the approval to request an additional API that would tell if a file is a link or not. There were two particular things that were emphasized during the discussion:
Also, there are some platform-specific properties of these link types that we need to keep in mind:
Proposed APInamespace System.IO.FileSystem
{
public abstract class FileSystemInfo
{
+ public bool IsLink { get; }
}
}Usage ExamplesFileInfo file = new FileInfo("/path/to/file-link");
Console.WriteLine(file.IsLink); // Prints true if file is a symlink to a file
DirectoryInfo directory = new DirectoryInfo("/path/to/dir-link");
Console.WriteLine(directory.IsLink); // Prints true if file is a symlink to a directory
FileInfo wrongfile = new FileInfo("/path/to/dir-link");
Console.WriteLine(wrongfile.IsLink); // Prints false because FileInfo is wrapping a directory link
FileInfo wrongdir = new FileInfo("/path/to/file-link");
Console.WriteLine(wrongdir.IsLink); // Prints false because DirectoryInfo is wrapping a file linkOptional additional designsIf desired during the review, we can also add static methods so users don't have to rely on namespace System.IO.FileSystem
{
public static class File
{
+ public static bool IsLink(string path);
}
}namespace System.IO.FileSystem
{
public static class Directory
{
+ public static bool IsLink(string path);
}
}cc @jozkee @mklement0 @tmds @iSazonov
|
carlossanlop
removed
the
untriaged
|
Just checking that |
|
@hamarb123, assuming that However, we need to get clarity on what
Given how NTFS works, (b) is invariably a subset of (a), given that any application can come along and define a new link type (as signaled by the name-surrogate flag) using application-specific non-standardized data to store the link information (plus a matching file-system filter). As argued before, the .NET APIs cannot and should not be expected to keep up with such custom link types. Perhaps the distinction will not matter much in practice: while the introduction of new reparse points in general seems likely, such as for third-party rehydrate-on-demand remote storage solutions, introducing new reparse points that are true links seems much less likely (Microsoft's own AppX reparse points are the only example that come to mind). |
|
@mklement0 I don't know much about the windows reparse points. On Unix, besides links, there are also mounts. I wouldn't expect |
|
Agreed, @tmds: Unix mount points appear as regular directories, not as (symbolic) links. NTFS volume mount points aka mounted folders are similar, though I presume they do present as
In other words: Conceptually, it also makes sense not to treat NTFS volume mount points, i.e. |
|
You are correct @mklement0, both junctions and mount points use |
|
Thanks for confirming the dual use of
They are essentially the same thing from an implementation detail perspective, which, unfortunately, is at odds with the abstract link API proposed in #24271 (comment):
There are two conceivable resolutions:
I'm now leaning toward (a):
|
|
@jozkee @carlossanlop @jeffhandley moving to 7.0 |
+1 I think it's proper when |
Background and Motivation
We recently got some APIs approved to provide the ability to create a symbolic link, and to return the target of a symbolic link.
The discussion continued after the approval to request an additional API that would tell if a file is a link or not.
There were a few particular things that were emphasized during the discussion:
Also, there are some platform-specific properties of these link types that we need to keep in mind:
FileInfowraps a link that points to a directory, there is no exception thrown, butExistsreturnsfalse. Same if aDirectoryInfowraps a link to a file. Our API should have a similar behavior.Proposed API
namespace System.IO.FileSystem { public abstract class FileSystemInfo { + public bool IsLink { get; } } }Usage Examples
Optional additional designs
If desired during the review, we can also add static methods so users don't have to rely on
FileSystemInfoinstances:namespace System.IO.FileSystem { public static class File { + public static bool IsLink(string path); } }namespace System.IO.FileSystem { public static class Directory { + public static bool IsLink(string path); } }cc @jozkee @mklement0 @tmds @iSazonov
The text was updated successfully, but these errors were encountered: