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.
