d2dyno1
commented
2 years ago Thanks for the suggestion!
Converting all paths to use URI formatting in Files is no easy task due to having them scattered all over the place and not having one common-ground for paths. However, we're slowly rolling out changes to unify storage abstractions in the codebase - #9544. The transition will be gradual where individual parts of the codebase will be reworked to feature new changes.
This new approach will allow us to abstract away paths into the implementation where we'll be able to (hopefully) easily implement URI paths. If you'd like to help speed up the process, we recommend you taking a look at Files.Sdk.Storage namespace. 🙂
@BEEDELLROKEJULIANLOCKHART
What's the Problem?
How paths are presented and managed by Files is inconsistent because it adheres to the old notion that software that is native to Windows does not accept forward-slashes to separate paths. However, Windows allows even decently low-level software to solely utilize the forward-slash to denote paths, rather than the backward-slash that Windows ultimately converts it to, to denote paths at or beneath the level of the file-system.
Solution/Idea
I propose that the “
file://” Uniform Resource Identifier be prepended to the presented path if the path is not relative, because the URI allows more simple formatting of local and external resources than current native implementations provide, and are easily prepended to the paths that I have previously described. Additionally, paths that contain the URI are properly parsed by software that accepts them, despite solely utilizing the forward-slash, because the URI does not accept alternative path-separators, and are more easily understood by internet-browsers. https://web.archive.org/web/https://datatracker.ietf.org/doc/id/draft-kerwin-file-scheme-07.html#unc-file-paths appears to demonstrate that Windows's Universal Naming Convention (UNC) paths are not problematic to convert, and certainly is superseded by this format.Alternatives
Nothing alternative provides similar consistency.
Priorities
I do not understand how to utilize this table, despite the template attempting to explain to me how to utilize it. I apologize.
Files Version
https://github.com/files-community/Files/releases/tag/v3.6 per https://github.com/files-community/Files/releases/latest
Comments
Very importantly, this obviously does not apply to relative paths, because a file URI is comprised partially of a path. That means that to prepend this to a relative path would be paradoxical.
This proposition was separated from https://github.com/files-community/Files/issues/9570#issuecomment-1214415689 because of what https://github.com/files-community/Files/issues/9570#issuecomment-1213514741 describes.
https://github.com/files-community/Files/issues/9570#issuecomment-1214415689 demonstrates that this has been accepted as not rejected, and that an intended refactor of the codebase should support it.
The previously described Solution/Idea should demonstrate the logic necessary to provide this should not be significantly difficult. (I would probably be able to implement this with regex in PowerShell if .NET didn't already support most of this.)