On Monday, 17 September 2018 at 12:37:13 UTC, Temtaime wrote:
On Sunday, 16 September 2018 at 22:49:26 UTC, Vladimir
Panteleev wrote:
To elaborate:
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir
Panteleev wrote:
If *YOU* are OK with the consequences of complexity,
implement this in YOUR code, but do not enforce it upon
others.
This is much better done in user code anyway, because you only
need to expand / normalize the path and prepend the prefix
only once (root of the directory tree you're operating on),
instead of once per directory call.
We could add a `string longPath(string)` function in Phobos
(no-op on POSIX, expands and prepends prefix on Windows). I
believe I suggested the same in the bug report years ago when
we discussed it.
It is absolutely not acceptable behavior. Complain to
Microsoft. The OS should not allow users to create or select
paths that programs cannot operate on without jumping through
crazy hoops.
Microsoft could have solved this easily enough:
extern(System) void AllowLongPaths();
Programs (or programming language runtimes) which can handle
paths longer than MAX_PATH could call that function. It can
also be used as a hint to the OS that file/directory selection
dialogs, as you mentioned, are allowed to select paths longer
than MAX_PATH.
It's problem with phobos.
It should be able handle all the paths whatever length they
have, on all the platforms without noising the user.
Even with performance penalty, but it should.
No, that's completely nuts!
A library, especially a standard library, should not introduce
new limitations, but pampering over the limitations of the
platform is not the right thing to do. If the platforms API is
piling POS, there's nothing a sane library can do about.
If your app writes to a FAT12 formatted floppy disk you don't
expect the library to implement code to alleviate its limitation,
like 8+3 filenames or fixed number of files in the root directory.
