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.

Reply via email to