On Saturday, 15 September 2018 at 09:47:25 UTC, WebFreak001 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)
The problem this causes can be disastrous. If some check fails
and runs code that isn't mean to run if the file exists, it
could destroy data.
I replaced many of the std.file functions with
executeShell(...) and using command line functions and they
work. But then my code was still failing and it was because
exist was returning false even though the file exists.
I'm sure this is not a big deal to some...
this is an issue with the Win32 API having that 260 character
limit. To work around it, you can use the special path syntax
Microsoft allows you to do, which will pass the string you
provide directly to the Filesystem instead of parsing it,
effectively raising your limit to whatever the Filesystem
limits to.
See also their official site on this:
https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation
C:/Some/Very/Long/Path.txt
should then become
\\?\C:\Some\Very\Long\Path.txt
converting / to \ is important because according to the docs
windows doesn't do it with the \\?\ prefix. You also have to
normalize the path beforehand (i.e. remove ..\ and .\ because
they would be treated as actual folder names)
To change a server path such as
\\share\public
you change it to
\\?\UNC\share\public
There are also some other useful things in there you might want
to look at too like the special files such as COM1
Yes, I did that and it worked for some(most) things it seems but
rmdir, for example, seems to fail.
Also, windows 10 does not have this problem nor does unicode so
maybe phobos needs to automatically do everything? If it did I
wouldn't have had this problem and wasted a day of my life trying
to figure out what is going on(I didn't design my program around
having to hack such things, I just assumed they would work,
because, after all, they should, right?). I then used execute
shell and had to work around that but still had problems because
I didn't think dirEntries would be failing.
Basically every file function will fail in some odd way(depending
on it's use) leaving one to deal with a whole complex of "bugs"
when there is really a common bug.
rmdir, now is failing but this may be some other bug introduced
by me in trying to fix other bugs.