Should IFileInfo's PhysicalPath always be null?

[AnthonyMastrean]

Except for the PhysicalFileInfo implementation from the PhysicalFileProvider, it seems like IFileInfo's PhysicalPath should always be null, especially when the implementation type doesn't use a physical file system.

This seems to be the case for known implementations like your own ManifestEmbeddedFileProvider's ManifestFileInfo; and the expectation for a custom implementation like a possible ZipArchiveFileProvider's ZipEntryFileInfo based on your ZipArchive and ZipEntry.

If this is the case, it would be nice to document this understanding... I suspect it's too late to suggest exposing PhysicalPath only on the PhysicalFileInfo.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.fileproviders.ifileinfo.physicalpath?view=dotnet-plat-ext-6.0#microsoft-extensions-fileproviders-ifileinfo-physicalpath

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

Issue Details

---

Except for the PhysicalFileInfo implementation from the PhysicalFileProvider, it seems like IFileInfo's PhysicalPath should always be null, especially when the implementation type doesn't use a physical file system.

This seems to be the case for known implementations like your own ManifestEmbeddedFileProvider's ManifestFileInfo; and the expectation for a custom implementation like a possible ZipArchiveFileProvider's ZipEntryFileInfo based on your ZipArchive and ZipEntry.

If this is the case, it would be nice to document this understanding... I suspect it's too late to suggest removing the PhysicalPath except on the PhysicalFileInfo.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.fileproviders.ifileinfo.physicalpath?view=dotnet-plat-ext-6.0#microsoft-extensions-fileproviders-ifileinfo-physicalpath

Author:	AnthonyMastrean
Assignees:	-
Labels:	Pri3, area-System.IO, :watch: Not Triaged
Milestone:	-

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

Issue Details

---

Except for the PhysicalFileInfo implementation from the PhysicalFileProvider, it seems like IFileInfo's PhysicalPath should always be null, especially when the implementation type doesn't use a physical file system.

This seems to be the case for known implementations like your own ManifestEmbeddedFileProvider's ManifestFileInfo; and the expectation for a custom implementation like a possible ZipArchiveFileProvider's ZipEntryFileInfo based on your ZipArchive and ZipEntry.

If this is the case, it would be nice to document this understanding... I suspect it's too late to suggest exposing PhysicalPath only on the PhysicalFileInfo.

https://docs.microsoft.com/en-us/dotnet/api/microsoft.extensions.fileproviders.ifileinfo.physicalpath?view=dotnet-plat-ext-6.0#microsoft-extensions-fileproviders-ifileinfo-physicalpath

Author:	AnthonyMastrean
Assignees:	-
Labels:	Pri3, area-System.IO, area-Extensions-FileSystem, :watch: Not Triaged
Milestone:	-

[eerhardt]

In the docs you linked, the summary states:

Return null if the file is not directly accessible.

What more are you looking for?

[AnthonyMastrean]

What does this mean?

directly accessible

[eerhardt]

My understanding would be the exact situations you described above:

This seems to be the case for known implementations like your own ManifestEmbeddedFileProvider's ManifestFileInfo; and the expectation for a custom implementation like a possible ZipArchiveFileProvider's ZipEntryFileInfo based on your ZipArchive and ZipEntry.

If the file is coming from inside another file, (.zip or an embedded manifest) it is not directly accessible. i.e. you can't access the file directly using an Operating System API / path.

Is there a more understandable expression that could be used here?

[AnthonyMastrean]

Yeah, we're getting somewhere. Without spending a lot of time in the physical file provider and related issues and docs, I didn't understand that "directly accessible" and/or "physical" meant something more like "accessible with the types and methods in System.IO.File.

[jozkee]

One alternative could be the following:
Return null if the file is not directly accessible.
Returns null if this IFileInfo does not represent a physical file.