phobo's std.file is completely broke!

Vladimir Panteleev thecybershadow.lists at gmail.com
Sun Sep 16 03:19:12 UTC 2018


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.



More information about the Digitalmars-d mailing list