phobo's std.file is completely broke!

[Nick Sabalausky (Abscissa)]

On 09/17/2018 11:27 AM, Patrick Schluter wrote:
> On Monday, 17 September 2018 at 12:37:13 UTC, Temtaime wrote:
>>
>> It's problem with phobos.
>> It should be able handle all the paths whatever length they have, on 
>> all the platforms without noising the user.
>>
>> Even with performance penalty, but it should.

This actually leads to an interesting point. Let's change gears for a 
moment to "API Design Theory"...

Suppose you implement API function X which takes Y as an argument. 
Question: Should X accept values (or types) of Y for which X fails? 
Answer: Ideally, no. At least to the extent realistically possible.

So what should a well-designed function X do when faced with known-to-be 
unsupported input Y?[1] Here are the possibilities[2]:

([1] "Unsupported" is defined here as "for the given input, the function 
does not correctly and successfully perform its intended goal".)

([2] Again, we're assuming "to the extent realistically possible" is 
still in play here.)

1. Add support for input Y to function X.
2. Reject input Y (via either: abort, throw or static compile error)
3. Accept input Y and allow one of the following to occur[3]: Silently 
fail to perform the expected task, silently do the wrong thing, or 
trigger an unclear error (assert/exception/compile) from deeper in the 
callstack. ([3] Note that which one of these three possibilities occurs 
is dependent on function X's exact implementation details.)

Of these three possibilities for a function X faced with unsupported 
input Y, the first two options are (in theory) acceptable[4]. The third 
possibility is absolutely not acceptable [to the extent realistically 
possible.]

([4] The library containing function X may impose additional 
restrictions on what is/isn't acceptable.)

So, what does this mean in our specific situation?

If good API design is followed, then any filesystem-based API, when 
running on Windows and faced with a path exceeding the local system's 
size limit, must do one of the following:

1. Modify Phobos to support long filepaths even on Windows versions 
below Win10 v1607.
2. Detect and reject any non-\\?\ path longer than MAX_PATH-12 bytes[5].
3. Provide a very good justification why possibilities #1 and #2 are 
sufficiently unrealistic/problematic.

([5] Note that the following still technically satisfy possibility #2 
since they do not involve passing unsupported input to the given 
function, but they could still be optionally determined unacceptable if 
desired: A. Rejecting all paths longer than MAX_PATH-12 bytes, even if 
\\?\-based. B. Rejecting too-long paths even on Win10 v1607+ with 
LongPathsEnabled set in the registry.)


> No, that's completely nuts!
> A library, especially a standard library, should not introduce new 
> limitations, but pampering over the limitations of the platform is not 
> the right thing to do.

This is debatable. Why, exactly, is pampering over pre-Win10-v1607's 
maximum non-\\?\ filepath length a bad thing? Exactly what problems does 
it cause?

> If the platforms API is piling POS, there's 
> nothing a sane library can do about.

That is patently untrue. It might be true in specific circumstances, but 
it is not generally true. If you believe it to be true in this specific 
case, then please explain *how*/*why* there is nothing the library can 
do about it.

> If your app writes to a FAT12 formatted floppy disk you don't expect the 
> library to implement code to alleviate its limitation, like 8+3 
> filenames or fixed number of files in the root directory.

The general rule of thumb is: "Typical situations should work as 
expected, atypical situations should be possible." Therefore, please 
explain *ANY* one of the following:

1. How writing to a FAT12 formatted floppy disk qualifies as a typical 
situation.

2. How abstracting over the MAX_PATH limitation makes writing to a FAT12 
formatted floppy impossible.

3. How my claim of "Typical situations should work as expected, atypical 
situations should be possible" is fundamentally wrong for D.