On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo
wrote:
For very long file names it is broke and every command fails.
These paths are not all that long but over 256 limit. (For
windows)
Please file a bug report with reproducible examples if you
believe it's a bug.
It's a bug, but how the hell can I reproduce examples when it
depends on the file system? Do you want me to make a VM image and
upload that too?
dirEntries(elem, SpanMode.shallow))
also fails. I've changed all my code over to using executeShell
and everything works except that now I can't even iterate over
directories that are too long.
This is ridiculous!
"It doesn't matter. When I compile a program or DLL in C/C++ and
many other languages, I use the Windows headers. These headers
define MAX_PATH to 260.
So the program will have the limit set by compile time, no matter
what you do in the OS later on. There is no advantage with this
setting for now, except that you now *may* pass long paths to API
functions w/o the infamous \\?\ prefix, but you have no guarantee
for it.
So to make this have the advantage that some people think it will
provide, we'd need:
wait until the Windows headers (in Visual Studio, or the DDK,
or the Platform SDK or whatever) is properly updated, i.e. the
runtime libs may take advantage of it
wait until MS forces this setting to be enabled all the time,
otherwise it's useless when it stays optional
not checking any more for the target OS in the application,
assuming Win 10 with the mentioned update
The latter will only be the case when an app can't target an
Windows version below 10. So all in all it will take years until
we get the advantage for standalone applications, and for TC
these things don't matter for now anyway.
"
enum size_t MAX_PATH = 260;
!!
Seems this is the problem! What a great failure scenario! How
bout at least check if the filename is larger than max path?
Seesh, the more I use D the more I regret it.
