Open TheSpydog opened 2 months ago
Tagging subscribers to this area: @dotnet/area-system-io See info in area-owners.md if you want to be subscribed.
cc @jbevain
Probably not directly related to this issue, but assuming relationships between file systems and platforms/OSes seems like a bad idea, as demonstrated by MatchCasing.PlatformDefault
.
The current Unix implementation of
Path.IsPathRooted
makes the assumption that all "rooted" filepaths begin with a/
. This assumption does not hold true for filesystems on certain video game consoles, which begin their filepaths with a multi-character mount name followed by a:/
.This is an issue we're tripping over on the NativeAOT console ports and it's not trivial to work around. Since the runtime calls IsPathRooted internally, we can't simply replace it in application code. And since this is in the managed side of the runtime, we can't simply make a change to the PAL to address it for the affected platforms.
For these console ports, we use stock .NET and public ILCompiler/Nuget packages. Any platform-specific logic is contained in a custom PAL. So to fix this issue properly with the current setup, we would need to abandon that approach and maintain a fork of
dotnet/runtime
just to work around this one problem, which is not ideal.One possible solution would be to move the IsPathRooted logic to the PAL. Another option would be to directly support the
<mountname>:/
-style roots in the C# IsPathRooted method.I understand this is outside of supported territory, but I still wanted to open the issue to bring it to your attention. If this isn't something that can/should be addressed upstream, then I'll try to come up with an alternative.