phobo's std.file is completely broke!

[Nick Sabalausky (Abscissa)]

On 09/19/2018 01:49 PM, Neia Neutuladh wrote:
> On Wednesday, 19 September 2018 at 08:54:42 UTC, Vladimir Panteleev wrote:
>> BTW, something follows from the above:
>>
>> write(`C:\` ~ (short path) ~  `con`) will fail
>>
>> but:
>>
>> write(`C:\` ~ (long path) ~ `con`) will succeed.
>>
>> This is just one issue I've noticed... there's probably more lurking.
> 
> Also, according to the internet:
> 
> write(chainPath(shortDirectory, "A "), "Win32 API strips trailing space");
> readText(chainPath(shortDirectory, "A")); // Win32 API strips trailing 
> space
> 
> But:
> write(chainPath(longDirectory, "A "), "Win32 API strips trailing space");
> readText(chainPath(longDirectory, "A")); // File not found
> 
> write(chainPath(shortDirectory, "A."));  // fails
> write(chainPath(longDirectory, "A."));  // succeeds
> 

Ok, excellent, now we're getting somewhere! :) Based on these actual 
concrete examples, yes, I can now grant that converting paths that are 
past the limit would indeed cause subtly different behaviour.

So clearly this needs to be an all-or-nothing deal...

> This is why we should use the exact same behavior in all cases. Always 
> use `\\?\` or never use it.

Yup.

> Since Windows path handling is weird by default, I'd prefer always using 
> `\\?\`. It's overhead, but not a huge amount of additional overhead 
> compared to filesystem manipulation.

My thoughts, exactly.

I'll also point out that this applies to user-code, too. Ie, with Phobos 
as it currently stands, user code has three options:

1. Never use `\\?\` and any time they compile their code on Windows, 
they must always be acutely aware of, and plan for, all of the fun 
little quirks of the Win33 file APIs.

2. Be *aware* of `\\?\` and always use it any time they compile their 
code on Windows (and always remember use longPath() or some such for all 
file operations when working on a cross-platform codebase).

3. Sometimes use `\\?\` and sometimes don't, and then deal with the fun 
little inconsistencies that creates.

I think ALL those options look really bad, but #2 seems the least 
terrible. But gee, wouldn't it be nice if we could just relieve that 
stupid burden on everybody of selecting and following #2? In the rare 
case where "doing the safe/correct thing by default" isn't good enough, 
there'd be nothing stopping anyone from calling the platform API 
directly if they really, really need to.

Opt-out is for safe, reliable, consistent things.
Opt-in is for difficult, tricky, dangerous things.
Not the other way around.