On Saturday, 15 September 2018 at 23:06:57 UTC, Jonathan M Davis wrote:
> On Saturday, September 15, 2018 6:54:50 AM MDT Josphe Brigmo via Digitalmars-d wrote:
>> 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.
>
> Using std.file should be on par with using the Windows API from C or C++. It doesn't try to fix the arguably broken behavior of the Windows API with regards to long paths but requires that the programmer deal with them just like they would in C/C++. The main differences are that the std.file functions in question use D strings rather than C strings, and they translate them to the UTF-16 C strings for you rather than requiring you to do it. But they don't do anything like add "\\?\" for you any more than the Windows API itself does that.
>
> If you consider that to be broken, then sorry. For better or worse, it was decided that it was better to let the programmer deal with those intricacies rather than trying to tweak the input to make it work based on the idea that that could have undesirable consequences in some circumstances. On some level, that does suck, but the Windows API does not make it easy to make this work like it would on a *nix system without introducing subtle bugs.
>
> If you find that the std.file functions don't work whereas using the same input to the Windows API functions in C/C++ would have, then there's a bug in the D code, and it needs to be fixed, but if it acts the same as the C/C++ code, then it's working as intended.
>
> - Jonathan M Davis

This attitude is unfortunately the cause of a lot frustration among cross-platform developers like me.

I chose D for my file scripting needs because it's a cross-platform language.

I expect that calling the function F on system X will work the same as calling that same function on system Y.

That's the contract in cross-platform programming.

Unfortunately D fails at being consistent.

I recently learned this lesson with my Resync tool.

No everybody wants the cross-platform to behave inconsistently.

For example, in the past I've implemented a proprietary cross-platform C++ game engine for Windows, PS2, Xbox and GameCube.

The games needed some tuning for the graphics, etc.

But code-wise, the engine made the games behave consistently across the different platforms.

This was all about making each method of each class behaving the same. As simple as that.

Indeed, on some platforms, the game engine also provided extra classes and/or methods to add some functionalities specific to these platforms.

But the common trunc was implemented (!) to behave the same. That was what our game developers expected...

On Monday, 17 September 2018 at 22:58:46 UTC, tide wrote:
> On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev wrote:
>> On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote:
>>>> Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution.
>>>
>>> Funny the other guy was saying to create a bugzilla issue.
>>
>> Do that *first*.
>
> That's already been done.
>
>>>> The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point.
>>>
>>> All these issues yet for some reason this function was included in the lot: https://dlang.org/phobos/std_path.html#absolutePath
>>> [...]
>>> This issue exists anyways, you'd only expand the path when it need to be used. If the file changes within milliseconds, I don't see that happening often and if it does there's a flaw in your design that'd happen even if the path didn't have to be constructed first.
>>
>> You've missed the point. Complexity breeds bugs and unexpected behavior. The expectation is that D's function to delete a file should do little else than call the OS function.
>>
>> If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others.
>
> version(Windows)
> {
>     if(path.length >= MAX_PATH)
>     {
>         // throw Exception(...) // effectively what happens now
>
>         // do workaround for
>     }
> }
>
> The complexity would only exist for those that need it. It'd be the difference between their code not working and code working. I'm sure people would rather their code work than not work in this case.
>
>>> So you pass a valid path (selected by a user through a UI) to rmDir, and it doesn't remove the directory. You think this is acceptable behavior?
>>
>> It is absolutely not acceptable behavior. Complain to Microsoft. The OS should not allow users to create or select paths that programs cannot operate on without jumping through crazy hoops.
>
> Not that crazy, you can get the actual absolutePath with one of the OS functions. It isn't that difficult of a workaround.

"Workaround" ;)

That's the problem actually.

As suggested previously, the std.file functions should call a GetPhysicalPath function which just returns the path unchanged on Linux and MacOS, and on Windows simply checks if the file path is smaller or not than the 256 character limit, and if needed makes it absolute and prefixes it.

This has no performance impact, and brings a consistent behavior across platforms.

THAT would be a nice solution for the cross-platform developers who erroneously think that the standard library is already Doing The Right Thing (TM) so that their code doesn't need platform-specific "workarounds"...

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.
>
> That's the contract in cross-platform programming.

Heh, I remember working around a filesystem that doesn't support unicode, I used bullet • as utf8 prefix and heuristically detected that names starting with that prefix are utf8 encoded and decoded from that.

On Tuesday, 18 September 2018 at 06:16:50 UTC, Ecstatic Coder wrote:
> This attitude is unfortunately the cause of a lot frustration among cross-platform developers like me.
>
> I chose D for my file scripting needs because it's a cross-platform language.
>
> 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.

How do you expect the following to "work the same" across all platforms:

	import std.stdio;
	import std.file;
	auto fn = "a.txt";
	auto f = File(fn, "w");
	remove(fn);

or this:

	import std.file;
	write("a", "a");
	write("A", "A");
	assert(readText("a") == "a");
	assert(readText("A") == "A");

There will always be inherent differences between platforms, because they are wildly different. Using this sentiment as an argument for Phobos to smooth over this one particular difference that you care about, and for which incidentally an apparent solution appears to be available, is fallacious.

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

That wasn't an easy task, but it made the life so much easier for the game programmers that it was obvious this was "the right thing" to do.

The fact that D's standard library has already bitten me several time with its platform specific problem clearly shows that you have chosen another path.

That's your right, but don't expect those who develop cross-platform tools in D to be happy to HAVE to put ugly "version ( ... )" stuff in their code when their software suddenly break on some platforms for unknown (= undocumented) reasons...

On 09/15/2018 09:54 AM, tide wrote:
> 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.

While that's admittedly all-too-true, filing a proper bug report is still an essential step.

Like you, I'm all for bringing attention to important issues on the newsgroup. However, it is CRUCIAL for this to be IN ADDITION to filing a bug report, and NOT INSTEAD of filing a bug report.

On 09/15/2018 08:09 PM, Vladimir Panteleev wrote:
> On Saturday, 15 September 2018 at 23:50:43 UTC, Josphe Brigmo wrote:
>> [...]
> 
> D is generally described as a system programming language. There is value in favoring a simple and obvious implementation ("do what I say") over going out of one's way to make usage simpler ("do what I mean"). The tradeoff is performance and complexity. Performance is generally an important factor for users of system programming languages, and complexity is a source of unforeseen problems in non-trivial use cases.
> 
> Consider, for example, how integers are treated in D and Python. D's integers are fixed-length and roll over on overflow. Python integers are bigints, which makes them slower, but can handle numbers of any size.
> 
>  From your posts, it sounds like you're looking for a programming language closer to Python than to D.
> 

D's philosophy is (or at least is supposed to be) "Whenever possible, the right thing should be default, alternatives should still be possible." (And if I'm mistaken on that, then I've very much chosen the wrong language to use.)

Note that this does not contradict D's integer behaviour, because changing that would be *prohibitively* expensive and cause the need for workarounds to be common yet very difficult (if even possible). Therefore, it is a justifiable exception to the rule.

By contrast, I find it difficult to believe that a fix to the OP's problem would be prohibitively expensive. Of course, maybe I'm wrong. And maybe, as some have vaguely suggested, the WinAPI makes a correct fix impossible. **BUT**, unfortunately, I (as well as the OP) have no way to know because there appears to be a distressingly blatant LACK of technical discussion on the specific OP problem itself. Instead, all I'm seeing is a bunch of high-level design-philosophy bickering left completely divorced from the specifics of the original problem in question.

Yes, the OP needs to file a bug report (and if he's already done so, then please post a link here for our reference). But sheesh, people, it's *no wonder* he's gotten upset about it. I would too, and so would most of the rest of you (I've seen it happen).

On Tuesday, 18 September 2018 at 19:33:00 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/15/2018 09:54 AM, tide wrote:
>> 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.
>
> While that's admittedly all-too-true, filing a proper bug report is still an essential step.
>
> Like you, I'm all for bringing attention to important issues on the newsgroup. However, it is CRUCIAL for this to be IN ADDITION to filing a bug report, and NOT INSTEAD of filing a bug report.

Correct. There's no point in having a lengthy discussion on the topic without a bug report because it'll just waste their time and then they'll complain that their bug is being ignored. Unless there is a change in the operation of this project, all bugs reported in the forum need to be addressed by telling them to file a bug report.

On Tuesday, 18 September 2018 at 19:57:09 UTC, Nick Sabalausky (Abscissa) wrote:
> Yes, the OP needs to file a bug report (and if he's already done so, then please post a link here for our reference).

It’s an old issue, and the OP posted the link a bit further up in this thread: https://forum.dlang.org/post/gyaswfyzwoofaozkizcu@forum.dlang.org

On 09/18/2018 06:14 PM, Bastiaan Veelo wrote:
> On Tuesday, 18 September 2018 at 19:57:09 UTC, Nick Sabalausky (Abscissa) wrote:
>> Yes, the OP needs to file a bug report (and if he's already done so, then please post a link here for our reference).
> 
> It’s an old issue, and the OP posted the link a bit further up in this thread: https://forum.dlang.org/post/gyaswfyzwoofaozkizcu@forum.dlang.org
> 

Ah, don't know how I managed to miss that. Thanks.