Inaccurate drive assumptions made by the Unix to Native Path procedure in os.nim

[Varriount]

When running under Windows, os.nim's unixToNativePath procedure assumes that the drive to use when converting to an absolute, native windows path is the 'C' drive.

Although correct for most cases, this method will likely fail to produce a desired result in cases where a program is running with a working directory that isn't the 'C' drive, such as when running from network shares or USB/SD drives.

Possible ideas are as follows (some of these can be combined or tweaked):

1. Use an optional 'drive' argument to determine the drive to use.
   • This argument would have no effect on systems that do not have a concept of drives, and would use a fallback method when the argument is not given.
2. Use the current drive the program runs on.
   • This is actually easy to implement, at least under Windows, for any path starting with a '' is an absolute path which references the 'current drive'.
3. Use the first directory in the path given to the procedure as the drive.
   • This could also be an optional method or argument. If not, then this method will break compatibility unless some heuristic is used to determine if the first part of the given path is a drive.
4. Use some magic pattern in the given path to specify the drive.

Personally, I favor a combination of the second option and either the first or third options. I feel that such approaches would handle the majority of common cases (which is using the current drive the program is run in), while still allowing the programmer to explicitly specify the drive to use.

I strongly advise against sticking with the current method - though it works in common household cases, it won't work for networks or portable drives without the use of cross-drive symlinks on the part of the user or programmer, and even those solutions won't always work depending on if symlink paths are resolved. As part of the standard library, the unixToNativePath procedure should be relatively flexible and able to work in as many cases as reasonably possible.

[gradha]

I've never seen a working path library which ignored drive letters. Along with #685 maybe the API should be rethought (where rethought means copy the API from anything else) and backwards compatibility broken before a 1.0 release.

[dom96]

I think a combination of 1 and 2 would work well. i.e. the current drive used by default but overridable through an extra argument to the proc.