On Thursday, 20 September 2018 at 19:49:01 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
On Thursday, 20 September 2018 at 03:23:36 UTC, Nick
Sabalausky (Abscissa) wrote:
(Not on a Win box at the moment.)
I added the output of my test program to the gist:
https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-output-txt
assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );
Actually it's crazier than that. The concatenation of the
current directory plus the relative path must be < MAX_PATH
(approx.). Meaning, if you are 50 directories deep, a relative
path starting with 50 `..\` still won't allow you to access
C:\file.txt.
Ouch. Ok, yea, this is pretty solid evidence that ALL usage of
non-`\\?\` paths on Windows needs to be killed dead, dead, dead.
If it were decided (not that I'm in favor of it) that we should
be protecting developers from files named " a ", "a." and
"COM1", then that really needs to be done on our end on top of
mandatory `\\?\`-based access. Anyone masochistic enough to
really WANT to deal with MAX_PATH and such is free to access
the Win32 APIs directly.
Decided to play around with this for a bit. Made a "proof of
concept" library:
https://github.com/marler8997/longfiles
It's just a prototype/exploration on the topic. It allows you to
include "stdx.longfiles" instead of "std.file" which will enable
the conversion in every call, or you can import "stdx.longfiles :
toLongPath" and use that on filenames passed to std.file.
There's also a test you can run
rund test/test_with_longfiles.d (should work)
rund test/test_without_longfiles.d (should fail)
NOTE: use "rund test/cleantests.d" to remove the files...I wasn't
able to via the windows explorer program.
