phobo's std.file is completely broke!

[Ecstatic Coder]

On Monday, 17 September 2018 at 22:58:46 UTC, tide wrote:
> On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir 
> Panteleev wrote:
>> On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote:
>>>> Nothing is "locked behind management". If you feel that some 
>>>> issue important to you is stalled, you can create a forum 
>>>> thread, or email Walter/Andrei to ask for a resolution.
>>>
>>> Funny the other guy was saying to create a bugzilla issue.
>>
>> Do that *first*.
>
> That's already been done.
>
>>>> The path needs to be normalized, which means that \.\ and 
>>>> \..\ fragments need to be removed away first. Depending on 
>>>> your interpretation of symlinks/junctions/etc., 
>>>> "foo/bar/../" might mean something else than "foo/" if "bar" 
>>>> is a reparse point.
>>>
>>> All these issues yet for some reason this function was 
>>> included in the lot: 
>>> https://dlang.org/phobos/std_path.html#absolutePath
>>> [...]
>>> This issue exists anyways, you'd only expand the path when it 
>>> need to be used. If the file changes within milliseconds, I 
>>> don't see that happening often and if it does there's a flaw 
>>> in your design that'd happen even if the path didn't have to 
>>> be constructed first.
>>
>> You've missed the point. Complexity breeds bugs and unexpected 
>> behavior. The expectation is that D's function to delete a 
>> file should do little else than call the OS function.
>>
>> If *YOU* are OK with the consequences of complexity, implement 
>> this in YOUR code, but do not enforce it upon others.
>
> version(Windows)
> {
>     if(path.length >= MAX_PATH)
>     {
>         // throw Exception(...) // effectively what happens now
>
>         // do workaround for
>     }
> }
>
> The complexity would only exist for those that need it. It'd be 
> the difference between their code not working and code working. 
> I'm sure people would rather their code work than not work in 
> this case.
>
>>> So you pass a valid path (selected by a user through a UI) to 
>>> rmDir, and it doesn't remove the directory. You think this is 
>>> acceptable behavior?
>>
>> It is absolutely not acceptable behavior. Complain to 
>> Microsoft. The OS should not allow users to create or select 
>> paths that programs cannot operate on without jumping through 
>> crazy hoops.
>
> Not that crazy, you can get the actual absolutePath with one of 
> the OS functions. It isn't that difficult of a workaround.

"Workaround" ;)

That's the problem actually.

As suggested previously, the std.file functions should call a 
GetPhysicalPath function which just returns the path unchanged on 
Linux and MacOS, and on Windows simply checks if the file path is 
smaller or not than the 256 character limit, and if needed makes 
it absolute and prefixes it.

This has no performance impact, and brings a consistent behavior 
across platforms.

THAT would be a nice solution for the cross-platform developers 
who erroneously think that the standard library is already Doing 
The Right Thing (TM) so that their code doesn't need 
platform-specific "workarounds"...