phobo's std.file is completely broke!

[Jonathan Marler]

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.