On Saturday, 15 September 2018 at 10:48:10 UTC, Vladimir Panteleev wrote:
> On Friday, 14 September 2018 at 19:42:39 UTC, Josphe Brigmo wrote:
>> "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;
>
> MAX_PATH only applies to static arrays (usually on the stack), i.e. code which does this:
>
> void doSomething()
> {
>     char fileName[MAX_PATH];
>     ...
>     SomeWindowsAPI(fileName);
> }
>
> D almost never does this - instead, it uses dynamically sized buffers which fit the entire file name. The only times MAX_PATH is used in Phobos is:
>
> - thisExePath (return path to current .exe file)
> - tempDir (return path to temporary directory)
>
> Obviously neither of these is related to the problems you're seeing.

You are missing the point, MAX_PATH is more than just phobos. It's built in to the windows design. Windows enforces it.

All ansi api calls are limited by MAX_PATH.

The way to fix it is to use the wide api calls which are not limited or to use other tricks.

Phobos *NEEDS* to be modified to work with these newer OS's.

You wouldn't like it if phobos limit something that it didn't need that you would use, would you?

File operations are so common that this stuff is relevant to all that use windows(and some that don't).

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...

If you are on Windows 10 version 1607 or later, there's a registry key you can set so that the default behavior of the Win32 API allows long file path names. But yah, the problem is Windows, its horrible file system and structure thereof. You'd have faced this problem using any other language like C or C++ included.

HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD)

On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo wrote:
> All ansi api calls are limited by MAX_PATH.
>
> The way to fix it is to use the wide api calls which are not limited or to use other tricks.
>
> Phobos *NEEDS* to be modified to work with these newer OS's.

Phobos already uses the wide APIs where it can.

Sometimes it uses the C APIs, though, for C compatibility. One example of this is std.stdio.File, which is based on C FILE*.

We can change std.file to use Windows APIs on Windows, no problem. That also will help with Unicode compatibility. However, as far as I can see, this has already been done for the cases you're having problems with (remove, and dirEntries which doesn't even have a C API).

So, it looks like all you need to do is prepend \\?\ to your paths. If it still doesn't work, the problem is with Windows. (Well, the problem was with Windows to begin with...)

On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo wrote:
> Phobos *NEEDS* to be modified to work with these newer OS's.

You need to look at the source code before posting. The code for remove is literally

DeleteFileW(name);

it is a one-line wrapper, and obviously uses the unicode version.

https://github.com/dlang/phobos/blob/master/std/file.d#L1047

On Saturday, 15 September 2018 at 12:38:41 UTC, Adam D. Ruppe wrote:
> On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo wrote:
>> Phobos *NEEDS* to be modified to work with these newer OS's.
>
> You need to look at the source code before posting. The code for remove is literally
>
> DeleteFileW(name);
>
> it is a one-line wrapper, and obviously uses the unicode version.
>
> https://github.com/dlang/phobos/blob/master/std/file.d#L1047


It doesn't matter, the fact is that something in phobos is broke. Do you really expect me to do all the work? The fact that using executeShell or "\\?\" solves 90% of the problems(maybe all of them) proves that phobos is not up to par.

It's simple as that.

just because it uses unicode does not mean squat if it doesn't work. The docs from microsoft said that the unicode functions are suppose to not have the limitation, but that doesn't mean that using them is the only fix.

The fact is, I write a directory parser and it failed, then I spend the next day trying to get something relatively easy to be fixed that should already have been fixed.

I'm also not the only one with the problem.

Maybe you should spend some time on windows and using std.file with long paths. I bet you have actually never done it so you are obviously to the problems.

There may be "simple" fixes, but the fact is that something is wrong or else my code would work(you can blame me all you want but the facts are the facts and the code only breaks on long file names).

https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation

It is a bit more complicated than just saying that phobos is doing it's job. Of course, it could be some windows issue but given that


https://issues.dlang.org/show_bug.cgi?id=8967

The point is that these things should be thoroughly tested before blaming the end user. Whatever is going on, it should. File IO is very basic and common and for code to break silently or in ways that does not make sense is bad, regardless of if I existed in this universe or not.

How hard is it for phobos to detect long files and absolute files and such and prepend if necessary?

For example,

https://issues.dlang.org/show_bug.cgi?id=8967

`
 Jay Norwood 2014-03-18 18:01:59 UTC

More surprising is  attempting to remove a long directory path and having an exception occur.

The libraries are already copying the user's string and adding the 0 termination prior to calling the windows api, so it seems to me to be a reasonable place to make other modifications if they are needed to accomplish the intended operation.
`

Which is almost 5 years old and exactly the same problem I'm having...

Yet it is somehow my fault for not reading the source of phobos to make sure it is using unicode api? Which it is and it's still failing!

and, of course, no followup on that bug has been done...

again, this is why I generally end up regretting using D. I thought it would be easier to write a small utility in a few hours and it's turned in to a few days. Any other sane language and I would have been done with 1/10th of the frustration and I'd actually have working code(which I still don't) because rmdir is till failing for some reason.

This is the typical mindset with D. There are all these "minor" problems that people(the D community pretends are all that big a deal but when you couple all these problems together it results in a very unpleasant programming experience(out of all the languages I've programmed in D is about the worse in this regard).

On Saturday, 15 September 2018 at 12:59:25 UTC, Josphe Brigmo wrote:
> This is the typical mindset with D. There are all these "minor" problems that people(the D community pretends are all that big a deal but when you couple all these problems together it results in a very unpleasant programming experience(out of all the languages I've programmed in D is about the worse in this regard).

You keep saying you regret using D, well let's go to C++ then. How are you going to solve this problem with C++?

It's a problem that can be worked around, if you are using the latest version of Windows it can be fixed by simply setting a registry entry. Then **all** your applications on your system will work with long file names.

On Saturday, 15 September 2018 at 12:59:25 UTC, Josphe Brigmo wrote:
> The libraries are already copying the user's string and adding the 0 termination prior to calling the windows api, so it seems to me to be a reasonable place to make other modifications if they are needed to accomplish the intended operation.

That only works for absolute paths.

> Yet it is somehow my fault for not reading the source of phobos to make sure it is using unicode api? Which it is and it's still failing!

Right. The problem is on the OS side.

> again, this is why I generally end up regretting using D.

Can you list some programming languages that achieve this task in a way you approve of?

> This is the typical mindset with D. There are all these "minor" problems that people(the D community pretends are all that big a deal but when you couple all these problems together it results in a very unpleasant programming experience(out of all the languages I've programmed in D is about the worse in this regard).

Please drop this tone, it will make you no allies.

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.

I feel people need to stop saying this. It feels like people are just being told to say this if there is a bug. There is a larger issue, Bugzilla doesn't and isn't working. Someone will probably throw up some stats about how many bugs are filed and how many are resolved. Those exist because someone working on Dlang comes across a bug that affects them, creates a patch for it first, then goes and creates a bugzilla entry and marks it resolved. Issues are rarely resolved by anyone other than the person that created the bug report to begin with. Or issues created by a team member is resolved by another team member.

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.

To add to that, a lot of the issues that get posted on the forum already have bug reports, and those reports have been there for *years*.