nemec
Is this a bug in the 'IPurePath.Join()' method? It creates a 'NEW' path, instead of joining the path from the 'Current Path'
Hello!
As I was working with the library, this method kept throwing me off:
The documentation says join current path with provided paths. I would think that it would only accept relative paths. However it accepts Absolute Paths (which is fine).
The behavior of the method is that it creates a new path, instead of joining the new paths with the existing current path.
Is this a bug? How would you like to handle this, or is this 100% acceptable?
Expected (based on the comments and xml descriptors)
- If an absolute Path is provided, an exception is thrown
- All provided paths are appended (joined) with the existing path
Actual
- A new path is created from the provided paths
- The new path is 100% unrelated to the previous 'current path' (It is brand new) and build from the provided paths
Just wondering your thoughts!
PS: I plan to submit some Zero-Allocation path checking code I have been working on in a pull request soon. I want to rip out some of that Regex stuff and replace it with quicker ReadonlySpan<char>, especially since we have a finite number of validation cases we are checking for.
So this behavior is based on the existing behavior of Path.Combine (and extended a bit to support Drives in an absolute path). It also matches with the behavior of using cd to change directories in cmd/ps (cd \Users in C:\Users\me changes to C:\Users)
However, if an argument other than the first contains a rooted path, any previous path components are ignored, and the returned string begins with that rooted path component.
https://docs.microsoft.com/en-us/dotnet/api/system.io.path.combine?view=net-6.0
It looks like there's now a Path.Join method in .NET Core that doesn't have this rooting behavior, which is unfortunate since people might turn to this library expecting the same even though it predates .NET Core by a few years.
I'm open to changing the behavior, but I'm disappointed that Path.Join ignores drives - it doesn't feel right to me that joining c:\Users with d:\SomeFolder becomes c:\Users\d:\SomeFolder.
PS: I plan to submit some Zero-Allocation path checking code I have been working on in a pull request soon. I want to rip out some of that Regex stuff and replace it with quicker ReadonlySpan
, especially since we have a finite number of validation cases we are checking for.
❤️❤️❤️ sounds great!
Oh, and one other fun thing: PowerShell maintains a separate current directory per drive, so cd c:me from within the c:\users directory changes to c:\users\me, but cd d:me tries to visit d:\me (unless you already visited a different folder in d: within the same session). I have no interest in going that far, but I think it makes sense if something like
new PureWindowsPath(@"C:\Users").Join("C:me");
became C:\Users\me
Maybe we just ignore the join if the initial path has a drive and someone attempts to join a path under a different drive.