On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote:
> On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
>> There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names.
>
> 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.

>> Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long?
>
> It's more than that.
>
> 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

> The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is.

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.

> All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right.

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?

On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote:
> On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
>> There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names.
>
> 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.
>
>> Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long?
>
> It's more than that.
>
> 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.
>
> The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is.
>
> All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right.

I'd agree with you that it isn't **Phobos** problem, but since most of the functions there aren't @system nor @nogc, I do believe it is. And if you want @system and @nogc with no safety you can go look into core.stdc for that.

On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote:
> On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
>> There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names.
>
> 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.
>
>> Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long?
>
> It's more than that.
>
> 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.
>
> The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is.
>
> All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right.

Well my mistake, seems absolutePath is just named incorrectly and should be more accurately named concatenatePath.

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

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

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

To elaborate:

On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev wrote:
> If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others.

This is much better done in user code anyway, because you only need to expand / normalize the path and prepend the prefix only once (root of the directory tree you're operating on), instead of once per directory call.

We could add a `string longPath(string)` function in Phobos (no-op on POSIX, expands and prepends prefix on Windows). I believe I suggested the same in the bug report years ago when we discussed it.

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

Microsoft could have solved this easily enough:

extern(System) void AllowLongPaths();

Programs (or programming language runtimes) which can handle paths longer than MAX_PATH could call that function. It can also be used as a hint to the OS that file/directory selection dialogs, as you mentioned, are allowed to select paths longer than MAX_PATH.

On Sunday, 16 September 2018 at 22:49:26 UTC, Vladimir Panteleev wrote:
> To elaborate:
>
> On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev wrote:
>> If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others.
>
> This is much better done in user code anyway, because you only need to expand / normalize the path and prepend the prefix only once (root of the directory tree you're operating on), instead of once per directory call.
>
> We could add a `string longPath(string)` function in Phobos (no-op on POSIX, expands and prepends prefix on Windows). I believe I suggested the same in the bug report years ago when we discussed it.
>
>> 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.
>
> Microsoft could have solved this easily enough:
>
> extern(System) void AllowLongPaths();
>
> Programs (or programming language runtimes) which can handle paths longer than MAX_PATH could call that function. It can also be used as a hint to the OS that file/directory selection dialogs, as you mentioned, are allowed to select paths longer than MAX_PATH.

It's problem with phobos.
It should be able handle all the paths whatever length they have, on all the platforms without noising the user.

Even with performance penalty, but it should.

On Monday, 17 September 2018 at 12:37:13 UTC, Temtaime wrote:
> On Sunday, 16 September 2018 at 22:49:26 UTC, Vladimir Panteleev wrote:
>> To elaborate:
>>
>> On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev wrote:
>>> If *YOU* are OK with the consequences of complexity, implement this in YOUR code, but do not enforce it upon others.
>>
>> This is much better done in user code anyway, because you only need to expand / normalize the path and prepend the prefix only once (root of the directory tree you're operating on), instead of once per directory call.
>>
>> We could add a `string longPath(string)` function in Phobos (no-op on POSIX, expands and prepends prefix on Windows). I believe I suggested the same in the bug report years ago when we discussed it.
>>
>>> 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.
>>
>> Microsoft could have solved this easily enough:
>>
>> extern(System) void AllowLongPaths();
>>
>> Programs (or programming language runtimes) which can handle paths longer than MAX_PATH could call that function. It can also be used as a hint to the OS that file/directory selection dialogs, as you mentioned, are allowed to select paths longer than MAX_PATH.
>
> It's problem with phobos.
> It should be able handle all the paths whatever length they have, on all the platforms without noising the user.
>
> Even with performance penalty, but it should.

No, that's completely nuts!
A library, especially a standard library, should not introduce new limitations, but pampering over the limitations of the platform is not the right thing to do. If the platforms API is piling POS, there's nothing a sane library can do about.
If your app writes to a FAT12 formatted floppy disk you don't expect the library to implement code to alleviate its limitation, like 8+3 filenames or fixed number of files in the root directory.

On 09/15/2018 06:57 AM, Josphe Brigmo wrote:
> 
> 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).
> 

As has already been said, *file a bug report*.

When told this before, instead of submitting a proper bug report, you simply moved your goalposts and began complaining about very vague, general things instead.

You appear to be less interested in getting this, or any other specific issue fixed than you are in simply ranting, griping and berating.

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.

On Monday, 17 September 2018 at 22:58:46 UTC, tide wrote:
> 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.

No good:

1. When hitting the situation where the extra logic does make a difference, and the program is operating on paths with some being under the the limit and some over, this will make it behave inconsistently depending on the data it's operating on.

2. When the registry key you mentioned is set, the workaround is unnecessary, and the extra logic can introduce unwanted behavior.

> Not that crazy, you can get the actual absolutePath with one of the OS functions. It isn't that difficult of a workaround.

Which OS function is that, for the record?