On 09/18/2018 05:25 AM, Vladimir Panteleev wrote:
> On Tuesday, 18 September 2018 at 06:16:50 UTC, Ecstatic Coder wrote:
>>
>> I expect that calling the function F on system X will work the same as calling that same function on system Y.
> 
> You ask for the impossible.

I think it's safe to assume a "...to the extent reasonably possible." suffixed to his statement.

On 09/15/2018 08:14 PM, Jonathan M Davis wrote:
> 
> The issue was reported in bugzilla quite some time ago.
> 
> https://issues.dlang.org/show_bug.cgi?id=8967
> 
> However, while Walter's response on it basically indicates that we should
> just close it as "won't fix," we never actually did

It's worth noting that the discussion made it very clear that Walter's viewpoint on the matter was based on his own misunderstanding (ie, mistakenly failed to notice that `\\?\` != `\\.\`) He never actually made any comment after that was pointed out.

On Tuesday, September 18, 2018 7:28:43 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 09/15/2018 08:14 PM, Jonathan M Davis wrote:
> > The issue was reported in bugzilla quite some time ago.
> >
> > https://issues.dlang.org/show_bug.cgi?id=8967
> >
> > However, while Walter's response on it basically indicates that we
> > should
> > just close it as "won't fix," we never actually did
>
> It's worth noting that the discussion made it very clear that Walter's viewpoint on the matter was based on his own misunderstanding (ie, mistakenly failed to notice that `\\?\` != `\\.\`) He never actually made any comment after that was pointed out.

If a clean, simple solution can be found that allows long paths on Windows to work seemlessly without subtle side effects, then I don't see why it can't be implemented, but it needs to be something that's not going to cause problems. Otherwise, it needs to be left up to the caller to do whatever happens to be correct for their particular circumstances. We want Phobos to work seemlessly across platforms where reasonably possible, but unfortunately, it's not always reasonable. Either way, Microsoft has clearly made a mess of this. So, I don't know how reasonable it is to work around it. Regardless, we either need to figure out a sane way to work around the problem (without causing new problems in the process) or document it so that the situation is clear.

- Jonathan M Davis

On 09/15/2018 06:40 AM, Vladimir Panteleev wrote:
> On Saturday, 15 September 2018 at 10:05:26 UTC, Josphe Brigmo wrote:
> 
>> Also, windows 10 does not have this problem
> 
> What do you mean by "windows 10"? Do you mean Explorer, the default file manager?
> 

According to MS docs:

"Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior."

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

It goes on to explain the registry setting for that.


>> 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, too, spent a LOT of time fighting the Windows filesystem APIs. See e.g. * https://dump.thecybershadow.net/d78d9911adc16ec749914b6923759454/longpathdelete.d (that also sets ownership/ACLs via external processes, as the C API is unreasonably complicated).
> 
> The problem is 100% due to Windows.
> 
> It was one of the big reasons why I moved to Linux for software development. Such problems do not exist there.
> 

Agreed, but this sounds to me like a perfect reason to abstract away as much as that garbage as we reasonably can. D's in the business of improving the user-experience of programming, not the promotion of one OS over another.

Bear in mind, the very point of plenty of things in Phobos, or any std lib for that matter, is to abstract away the need to waste everyone's time making them fiddle about with pointless little OS differences. Sure, there are going to be things that can't be reasonably abstracted away, but that's FAR from justifying not doing what we can. Again: normal expectations should be the default and just work, exceptional needs should still be possible.

And at least for me, moving from Windows to Linux would have been a LOT harder if it weren't for the OS abstractions that are already in Phobos.

On 09/18/2018 09:46 PM, Jonathan M Davis wrote:
> On Tuesday, September 18, 2018 7:28:43 PM MDT Nick Sabalausky (Abscissa) via
> Digitalmars-d wrote:
>>
>> It's worth noting that the discussion made it very clear that Walter's
>> viewpoint on the matter was based on his own misunderstanding (ie,
>> mistakenly failed to notice that `\\?\` != `\\.\`) He never actually
>> made any comment after that was pointed out.
> 
> If a clean, simple solution can be found that allows long paths on Windows
> to work seemlessly without subtle side effects, then I don't see why it
> can't be implemented, but it needs to be something that's not going to cause
> problems. Otherwise, it needs to be left up to the caller to do whatever
> happens to be correct for their particular circumstances. We want Phobos to
> work seemlessly across platforms where reasonably possible, but
> unfortunately, it's not always reasonable. Either way, Microsoft has clearly
> made a mess of this. So, I don't know how reasonable it is to work around
> it. Regardless, we either need to figure out a sane way to work around the
> problem (without causing new problems in the process) or document it so that
> the situation is clear.
> 

Exactly. And this is precisely why I'm irritated by just how much of this entire thread has been meaningless high-level philosophical hand-wringing, with barely any attention paid to the technical details of the problem itself.

Though I admit, I've allowed myself to get dragged into it, too. So allow me to rectify that:

1. For reference, here is the relevant MS documentation:
https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#file-and-directory-names

2. For reference, here is the existing bug report discussion:
https://issues.dlang.org/show_bug.cgi?id=8967

3. Building on what Vladimir and Jay have said in the bug report, I propose we do this:

- We add a public function to Phobos which takes a a UTF-8 path and does the following:
    - No-op outside of Windows
    - No-op if the path is less than MAX_PATH-12 bytes. (Worrying about the case where the real limit is MAX_PATH-1 would be inconsequential and thus needless.)
    - No-op if the path begins with "\\" (and is therefore either a network share path, a "\\.\" device path, is already a "\\?\" path, or is just some undetectable malformed path that happens to look like one of the above)
    - Otherwise, returns:
        toUTF16z(buildNormalizedPath("\\?", path.toAbsolute))
    - By "no-op" above, I really mean: toUTF16z(path)
- In all cases where Phobos passes a path to WinAPI, the path is first passed through this function (except for any specific cases where it can be shown that the path should NOT be passed through this function).

4. What technical problems does this proposal have?

5. For each technical problem with the proposal: How can the proposal be adjusted to compensate? Or, why can the technical problem NOT be reasonably solved? Or in general: How should this proposal be modified, and why?

On Wednesday, 19 September 2018 at 02:20:45 UTC, Nick Sabalausky (Abscissa) wrote:
> 3. Building on what Vladimir and Jay have said in the bug report, I propose we do this:

This has been proposed before in this thread. I don't think it's a good idea:

https://forum.dlang.org/post/bqsjebjxuljlqusaobst@forum.dlang.org

I proposed something a little different:

https://forum.dlang.org/post/dnlbtkmdcjucqetkwsey@forum.dlang.org

On Wednesday, 19 September 2018 at 01:50:54 UTC, Nick Sabalausky (Abscissa) wrote:
> And at least for me, moving from Windows to Linux would have been a LOT harder if it weren't for the OS abstractions that are already in Phobos.

It's one thing to call unlink on POSIX and RemoveFileW on Windows. Another is adding a good deal of extra logic that performs additional OS calls and generates additional GC garbage to work around API problems even on systems that don't need it.

On Tuesday, 18 September 2018 at 18:04:19 UTC, Ecstatic Coder wrote:
>> There will always be inherent differences between platforms, because they are wildly different.
>
> Right.
>
> Technically the PS2 console, the GameCube and the Xbox console were very different from each other, so I had no choice but to implement low-level abstraction function (GetPhysicalPath() etc) to make the file system classes work similarly across all four systems.

Do the PS2, GameCube and Xbox filesystems all have identical file path limits?

And, did any of the paths in your game exceed 260 characters in length?

These comparisons are not helpful.

> Do the PS2, GameCube and Xbox filesystems all have identical file path limits?

Guess ;)

> And, did any of the paths in your game exceed 260 characters in length?

No. But the suggested GetPhysicalPath() solution would also work equally well in this case.

> These comparisons are not helpful.

None would ever be, considering you obviously have decided to ignore such a simple solution to the 260 character limit...

On Wednesday, 19 September 2018 at 05:24:24 UTC, Ecstatic Coder wrote:
> None would ever be, considering you obviously have decided to ignore such a simple solution to the 260 character limit...

Add "ad hominem" to your pile of fallacies, I guess. I've addressed it twice in this thread already - it is problematic for technical reasons. It seems you are the one ignoring the problems with it...