Recent searches
Search options
contradiction found in the rust stdlib docs, windows devs plz weigh in:
(1) Path::is_absolute() says:
On Windows, a path is absolute if it has a prefix and starts with the root:
c:\windowsis absolute, whilec:tempand\tempare not.
(2) MSDN on file paths directly contradicts this:
A file name is relative to the current directory if it does not begin with one of the following:
- A UNC name of any format, which always start with two backslash characters (
"\\"). For more information, see the next section.- A disk designator with a backslash, for example
"C:\"or"d:\".- A single backslash, for example,
"\directory"or"\file.txt". This is also referred to as an absolute path.
i get that starting with \\ invokes special windows magicks, but the rust stdlib docs are saying directly that \temp is not absolute, while MSDN directly states the exact opposite. i don't think the docs are misaligned with the code either, since the code very directly checks (a) if it has a root (starting with \) then (b) if it has a prefix (starting with C:). this seems flatly wrong.
@hipsterelectron The MSDN docs seem to have their own definition of "absolute". If you don't provide a drive letter, then \temp is "absolute" within the current drive.
@notclacke this sounds like something you would be told in a horror movie right before your friend suddenly disappears
@notclacke the definition i care about is: it's not relative to the current working directory, right? it's referring to some other external mountpoint?
@notclacke because if so then the problem would seem to be the desire to define Path::is_relative() as !Path::is_absolute(), which is apparently not the case on windows? cc @dalias (i thought you were kidding with your earlier remark lol)
@hipsterelectron @dalias Yeah, I would say \temp is neither relative nor absolute. 
@notclacke @hipsterelectron Exactly. And it's so stupid that Microsoft hasn't fixed this artifact of DOS. "Current drive" should be locked at C: and \ should thereby always be relative to that. And C: should be a virtual absolute root, not the first hard drive.
@dalias @notclacke @hipsterelectron Windows drives are the source of so much inconsistency! They really should've gotten rid of this nonsense. DOS compatibility is already all over the place anyway.
Besides the whole "absolute" path with additional state nonsense, there's also the whole thing with inconsistent working directory handling, where they inject messed up pseudo env vars to keep behaviour "compatible" with DOS. That's a fun one to look into, for anyone wanting to be *more* horrified.
@lunarood Horrify us! I grew up fighting the "com bat files", as some of us called them, and moved up from there through Windows 3.0, 3.1, 95 and XP, but this quirk sounds new to me.
@dalias @hipsterelectron
@notclacke @hipsterelectron @lunarood You don't remember typing A:, doing some stuff on floppy, then typing C: and getting back to the same dir you were in on the HDD?
That wasn't just COMMAND.COM shell behavior, but actual OS state in DOS that Windows preserved as local to the process. 
@dalias @notclacke @hipsterelectron Yeah, this.
Some more details: https://stackoverflow.com/a/53078745
@dalias Yes! I described that elsewhere in the thread. Each drive has a current directory, and your actual current directory is determined by your current drive and the current directory of that drive. Is that state what you mean by pseudo environment variable?
@hipsterelectron @lunarood
@notclacke @dalias @hipsterelectron Not quite. What I was referencing, which Cassandrich expanded upon, is the particular way in which this DOS behaviour was "ported" to Windows.
It's handled in the process environment, rather than at the OS level. Technically they are actual environment variables, so my "pseudo" was kinda misleading, but they use a mangled naming scheme to avoid collisions with other vars.
The link I posted in another reply goes into more detail (some of it in the comments).
@lunarood Aha! Gotcha. Making them actual environment variables with special names rather than process attributes is an "interesting" choice. They do affect the behavior of native Windows processes, right?
EDIT: They DON'T??! (found the stackoverflow link elsewhere in the thread)
@dalias @hipsterelectron
Whereas in Win32, there is only one current directoryI have been lied to by CMD.EXE.
So does
D:some_dir even have meaning in the system? I'll have to find a Windows machine and experiment.web.archive.org/web/20180813013919/https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133
/via stackoverflow.com/questions/53078528/how-to-get-current-working-directory-of-another-drive-in-batch/53078745#comment93054937_53078745
/via mastodon.gamedev.place/@lunarood/114144521393298888
@lunarood @dalias @hipsterelectron
@notclacke @hipsterelectron @lunarood Wow this is even more cursed than I expected. So what does d:foo mean when d: isn't the drive of the real current working directory? Same as d:\foo?
And what does \foo mean? Is it relative to the root of the drive letter of the current working directory? Or what?
@dalias @notclacke @hipsterelectron Haha, looks like you are all thoroughly horrified! Mission accomplished! 
As for those two questions about the paths... my assumption is that, on Windows (without cmd.exe), the answer is "yes" in both cases. Though I can't verify this... it's been years since I had to deal with a Windows box.
@dalias @notclacke @hipsterelectron Now, tying this all back to d@nny's original issue... taking all the variations in behaviour into account... I think we can all confidently say that the full, definitive, exhaustive answer is: 