On 09/19/2018 02:26 AM, Vladimir Panteleev wrote:
On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky
(Abscissa) wrote:
[...]
Someone mentioned in this thread that .NET runtime does do the long-path
workaround automatically. One thing we could do is copy EXACTLY what C#
is doing.
This is a complete textbook example of the "appeal to authority" fallacy.
If an approach is valid, then it stands on its own merits regardless of
whether or not Microsoft implemented it.
If an approach in invalid, then it fails on its own demerits regardless
of whether or not Microsoft implemented it.
What MS has or hasn't implemented and released is completely irrelevant
WRT validity and correctness.
What it *might* be useful for is as a starting point for further
exploration. But that is all.
However, there are still drawbacks to this:
- There is still the matter of overhead (one OS API call
(GetCurrentDirectory) and at least one GC allocation (for the current
directory buffer)).
If one extra OS API call + allocation per std.file API call is
unacceptable, then explain how it is unacceptable. I disagree that it is
significant enough to be unacceptable.
If a user needs to optimize their
already-working-for-all-accepted-inputs application, then they are free
to do so. I argue that building this into the standard library's default
behaviour amounts to mandatory premature optimization, prioritizing
premature optimization over correctness. Prove me wrong.
- Using paths longer than MAX_PATH is an exceptional situation. Putting
the workaround in the main code path penalizes 99.9% of use cases.
I have many filepaths on my system right now which exceed MAX_PATH in
total length. I submit that this "penalty" you speak of is nothing more
than a trivial performance boost at the expense of correctness.
Furthermore, I submit that long paths which need extra optimization are
MORE exceptional than long paths which do NOT need extra optimization.
- The registry switch in newer Windows versions removes the need for
this workaround, so systems with it enabled are penalized as well.
Using the Phobos-based workaround on a system WITH the longpath setting
supported and enabled results in slightly reduced performance (which can
be overridden and optimized when necessary). Note that it is possible
(and very simple) to detect this situation and handle it optimally by
skipping the workaround.
OTOH, NOT using the Phobos-based workaround on a system where the
longpath setting is NOT supported *OR* NOT enabled results in erroneous
behavior. Not something as trivial as slightly-degraded performance on
IO access.
The superior default is clear: Use the workaround except where the
workaround in known to be safe to omit.
- There is still the matter regarding special filenames,
If you're referring to NUL, COM1, COM2, etc, then this is completely
orthogonal.
as well as
whet her the expected behavior is really to succeed and create paths
inaccessible to most software, instead of failing.
Ok, suppose we decide "Sure, we have reason to believe there may be a
significant amount of software on Windows which fails to handle long
paths and we want to ensure maximum compatibility with those admittedly
broken programs." That's fine. I can get behind that. HOWEVER, that does
NOT mean we should leave our APIs as they are, because currently, our
APIs fail at that goal. Instead, what it really means is that our APIs
should be designed to *REJECT* long paths with an appropriately
meaningful error message - and a reasonable workaround - and NOT to
blindly just pass them along as they currently do.
Either way, Phobos needs changed:
Do you believe D should prevent its own software from being broken on
long paths? Then Phobos should be modified to detect and fix long paths.
Do you believe D should permit breakage on long paths and encourage its
programs to play nicely with other non-D Windows software that is *also*
broken on long paths? Then Phobos should be modified to detect and
*reject* long paths.
Either way, the current Phobos behavior is clearly the worst of both
worlds and needs modification.
