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.
Well my mistake, seems absolutePath is just named incorrectly and
should be more accurately named concatenatePath.