phobo's std.file is completely broke!

[tide]

On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev 
wrote:
> On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
>> There are a lot of issues that aren't simple bugs that just 
>> anyone can fix. They are issues that are locked behind 
>> management. One's that are 4 years old for example, they are 
>> probably some bug locked behind management. That's why they 
>> get so old. From the comments it is not clear that a pull 
>> request wouldn't be accepted to fix the issue. Personally I 
>> think phobos should not exception for long file names.
>
> 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.

>> Walters concern is that the path will change unexpected for 
>> the user. Where does that matter for something like rmDir ? 
>> The user passes a long path, and rmDir swallows it, never to 
>> be seen again by the user. What does it matter if the path 
>> gets corrected if it is too long?
>
> It's more than that.
>
> 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

> The path also needs to be absolute, so it has to be expanded to 
> a full path before it can be prefixed with the UNC prefix. 
> Given how the current directory is state tied to the process 
> (not thread), you get bonus race condition issues. There's also 
> issues like the current directory object being renamed/moved; 
> then a relative path will no longer correspond to what the 
> program thinks the absolute paths is.

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.

> All things considered, this goes well into the territory of 
> "not D's problem". My personal recommendation: if you care 
> about long path names, use an operating system which implements 
> them right.

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?