-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API Proposal]: Implement IDirectoryContents on PhysicalDirectoryInfo at MS.Extensions.FileProviders.Physical #86354
Comments
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsBackground and motivation
The default implementation, The problem:
API Proposalnamespace Microsoft.Extensions.FileProviders.Physical
{
public class PhysicalDirectoryInfo : IFileInfo, IDirectoryContents
{
// IDirectoryContents implementation
} API Usageclass Utils
{
public static void RecursivelyTraverseTree(IDirectoryContents contents)
{
foreach (var entry in contents)
{
if (entry.IsDirectory)
{
if (entry is IDirectoryContents childContents)
{
RecursivelyTraverseTree(childContents);
}
}
}
}
} Alternative DesignsAlternatively, PhysicalDirectoryInfo could implement Anyway, I am open to proposals to know how to traverse a file system tree based on IFileInfo abstractions, without taking assumptions about the underlaying implementation. RisksNo response
|
As a workaround, you could just create a PhysicalDirectoryContents using PhysicalDirectoryInfo.PhysicalPath, no? |
No, the point of using the interfaces is to have an abstraction layer that does not implicitly assume there's a physical path. In fact I want to create virtualized file systems, or file system from within archives, where PhysicalPath would throw an exception. |
Looks good as proposed namespace Microsoft.Extensions.FileProviders.Physical
{
public partial class PhysicalDirectoryInfo : IFileInfo
+ , IDirectoryContents
{
// IDirectoryContents implementation
} |
Background and motivation
Microsoft.Extensions.FileProviders.Abstractions
provides a basic set of interfaces that allow accessing the file system.The default implementation,
Microsoft.Extensions.FileProviders.Physical
, wrapsFileInfo
andDirectoryInfo
, and the context is initialized using aPhysicalFileProvider
, which, as I understand it, might be used at the directory root, or any directory that can be considered the "local root"The problem:
PhysicalFileProvider
implementsIDirectoryContents
which gives the list ofIFileInfo
items contained in the root directory, which are represented by both files and directories , the latter being implemented by aPhysicalDirectoryInfo
, which implementsIFileInfo
, but does not implementIDirectoryContents
, and as a consequence of this, it's not possible to traverse the file system tree beyond the 1st directory level provided byPhysicalFileProvider
API Proposal
API Usage
Alternative Designs
Alternatively, PhysicalDirectoryInfo could implement
IFileProvider
instead ofIDirectoryContents
because the latter can be retrieved from the former.Anyway, I am open to proposals to know how to traverse a file system tree based on IFileInfo abstractions, without taking assumptions about the underlaying implementation.
Risks
No response
The text was updated successfully, but these errors were encountered: