Interestingly, "unholy mixes" of slashes only always work properly in old Windows paths! I found this out when debugging an open source project where '/file.txt' (hardcoded as a forward slash) was appended to a "\\?\" path.
Microsoft introduced "extended paths" to accommodate Unicode and paths longer than 260 characters (i.e. "C:\<256-char string>"). These can be prefixed by "\\?\", which sadly does not support slash mixes. Rust's standard library `canonicalize` function, for example, returns "\\?\" paths!
(* EDIT: I originally wrote some historical inaccuracies, see ynik's reply below for the corrections. Thank you ynik!)
The "\\?\" extended-length paths have existed for a long time; I think since Windows 2000 at least.
The Windows kernel and NTFS have always supported paths up to 32k characters; only the Win32 path normalization logic was limited to MAX_PATH. The "\\?\" prefix skips the normalization logic, thus allowing apps to use the full path length.
The Windows 10 change in 2016 is something different: if an application opts in (via manifest) AND the LongPathsEnabled registry key is set, long paths will be supported by some (not all) Windows API functions even without the "\\?\" prefix. These new long paths support a mixture of slashes just fine.
Thanks for pointing these out, very interesting! I amended the parent so others aren't misinformed (with credit to you). I discovered this because the Rust standard library's `canonicalize` function actually returns paths in extended-length path syntax. With credit to Rust, their docs actually point out that you must append paths that are backslash-delimited: https://doc.rust-lang.org/std/fs/fn.canonicalize.html
Indeed. Although technically it's UCS-2 as the low level stuff doesn't understand modern unicode; it just treats it all as a stream of wide chars. It's up to applications to interpret it.
According to this[0] the path limit is nearer 32739*2 bytes as a drive like "C:" gets expanded to "\Device\HarddiskVolume1".
Except if it's a compound emoji, which takes multiple codepoints -> more than 4 bytes.
So really the takeaway is that "character" is highly ambiguous nowadays and shouldn't be used anymore, use one of these instead:
* UTF-n code unit
* Unicode code point
* Grapheme Cluster
* Extended Grapheme Cluster
For the latter one also needs to specify the version of Unicode they're talking about, since every new compound emojis changes the definition of "Extended Grapheme Cluster".
Microsoft introduced "extended paths" to accommodate Unicode and paths longer than 260 characters (i.e. "C:\<256-char string>"). These can be prefixed by "\\?\", which sadly does not support slash mixes. Rust's standard library `canonicalize` function, for example, returns "\\?\" paths!
(* EDIT: I originally wrote some historical inaccuracies, see ynik's reply below for the corrections. Thank you ynik!)
From the docs: "File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix." - https://docs.microsoft.com/en-us/windows/desktop/FileIO/nami...