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.
>
>> 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.
>
> 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.
>
> 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.

I'd agree with you that it isn't **Phobos** problem, but since 
most of the functions there aren't @system nor @nogc, I do 
believe it is. And if you want @system and @nogc with no safety 
you can go look into core.stdc for that.