On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky (Abscissa) wrote:
> What drives me mad is when allegedly cross-platform tools deliberately propagate non-cross-platform quirks that could easily be abstracted away and pretend that's somehow "helping" me instead of making a complete wreck of the whole point of cross-platform.

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
>A strictly conforming application must not require a larger value for correct operation.
{_POSIX_NAME_MAX}
    Maximum number of bytes in a filename (not including terminating null).
    Value: 14
{_POSIX_PATH_MAX}
    Maximum number of bytes in a pathname.
    Value: 256

On 09/20/2018 03:38 AM, Kagamin wrote:
> On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky (Abscissa) wrote:
>> What drives me mad is when allegedly cross-platform tools deliberately propagate non-cross-platform quirks that could easily be abstracted away and pretend that's somehow "helping" me instead of making a complete wreck of the whole point of cross-platform.
> 
> http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
>> A strictly conforming application must not require a larger value for correct operation.
> {_POSIX_NAME_MAX}
>      Maximum number of bytes in a filename (not including terminating null).
>      Value: 14
> {_POSIX_PATH_MAX}
>      Maximum number of bytes in a pathname.
>      Value: 256

I generally omit obvious disclaimers such as "to a reasonable extent" and "within reason".

I've yet to see a current, non-esoteric *nix that has such limitations. Particularly that first one. If it were a realistic thing, like it is with Windows, then I'd be all for a similarly simple workaround if such exists. But to my knowledge, that is more theoretical/historical than it is realistic.

On 09/19/2018 11:15 PM, Vladimir Panteleev wrote:
> On Wednesday, 19 September 2018 at 06:11:22 UTC, Vladimir Panteleev wrote:
>> One point of view is that the expected behavior is that the functions succeed. Another point of view is that Phobos should not allow programs to create files and directories with invalid paths. Consider, e.g. that a user writes a program that creates a large tree of deeply nested filesystem objects. When they are done and wish to delete them, their file manager fails and displays an error. The user's conclusion? D sucks because it corrupts the filesystem and creates objects they can't operate with.
> 
> You don't even need to use crazy third-party software.
> 
> Try this program:
> 
>      mkdir(`\\?\C:\ a \`);
>      write(`\\?\C:\ a \a.txt`, "Hello");
> 
> Then, try doing the following:
> 
> - Double-click the created text file.
> 
> - Try deleting the directory from Explorer (by sending it to the recycle bin).
> 
> - Try permanently deleting it (Shift+Delete).
> 
> - Try renaming it.
> 
> All of these fail for me. Deleting the directory doesn't even show an error - nothing at all happens.
> 
> When the OS itself fails to properly deal with such files, I don't think D has any business in *facilitating* their creation by default.
> 

I used to be a pure Windows user for a long, long time. Trust me, if you're using Windows, you run into PLENTY of ways to generate files that explorer can't handle. Even the system's own commandline makes their creation trivial (it also makes it trivial remove/rename such files, too). Very little else on Windows has the same bizarre, inconsistent-with-the-OS-itself limitations that explorer has. It's a jungle. Welcome to Windows. *shrug*

On 09/20/2018 03:59 AM, Nick Sabalausky (Abscissa) wrote:
> On 09/19/2018 11:15 PM, Vladimir Panteleev wrote:
>>
>> When the OS itself fails to properly deal with such files, I don't think D has any business in *facilitating* their creation by default.
>>
> 
> I used to be a pure Windows user for a long, long time. Trust me, if you're using Windows, you run into PLENTY of ways to generate files that explorer can't handle. Even the system's own commandline makes their creation trivial (it also makes it trivial remove/rename such files, too). Very little else on Windows has the same bizarre, inconsistent-with-the-OS-itself limitations that explorer has. It's a jungle. Welcome to Windows. *shrug*

In any case, the last thing Windows users need is more software that gives them the same "It's not even compatible with its own freaking native filesystem" headaches explorer already gives them.

(Not that I don't have opposite beefs with Linux - Linux could use a lot LESS software that happily supports file/dir names with forward slashes and hidden control codes in them. Ugh, ya can't win anywhere in computing...)

On Thu, Sep 20, 2018 at 03:45:07AM +0000, Vladimir Panteleev via Digitalmars-d wrote: [...]
> Actually it's crazier than that. The concatenation of the current directory plus the relative path must be < MAX_PATH (approx.). Meaning, if you are 50 directories deep, a relative path starting with 50 `..\` still won't allow you to access C:\file.txt.

Wow. I didn't know Windows came with its own chroot() functionality!

</sarcasm> :-P


T

-- 
My program has no bugs! Only undocumented features...

On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
> On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky (Abscissa) wrote:
>> (Not on a Win box at the moment.)
> 
> I added the output of my test program to the gist:
> https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-output-txt 
> 
> 
>> assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );
> 
> Actually it's crazier than that. The concatenation of the current directory plus the relative path must be < MAX_PATH (approx.). Meaning, if you are 50 directories deep, a relative path starting with 50 `..\` still won't allow you to access C:\file.txt.
> 

Ouch. Ok, yea, this is pretty solid evidence that ALL usage of non-`\\?\` paths on Windows needs to be killed dead, dead, dead.

If it were decided (not that I'm in favor of it) that we should be protecting developers from files named " a ", "a." and "COM1", then that really needs to be done on our end on top of mandatory `\\?\`-based access. Anyone masochistic enough to really WANT to deal with MAX_PATH and such is free to access the Win32 APIs directly.

On 09/19/2018 11:27 PM, Vladimir Panteleev wrote:
> On Thursday, 20 September 2018 at 03:25:05 UTC, Nick Sabalausky (Abscissa) wrote:
>> On 09/19/2018 11:23 PM, Nick Sabalausky (Abscissa) wrote:
>>>
>>> rmdir(path);
>>
>> Obviously meant "rmdir(dir);" here. Editing mishap.
> 
> and MAX_PATH instead of MAX_LENGTH, and absolutePath instead of toAbsolutePath, and !isAbsolute instead of isRelativePath, but I understood what you meant :)
> 

Ugh, yea, the perils of coding from memory ;)

On Thursday, 20 September 2018 at 19:49:01 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
>> On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky (Abscissa) wrote:
>>> (Not on a Win box at the moment.)
>> 
>> I added the output of my test program to the gist:
>> https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-output-txt
>> 
>> 
>>> assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );
>> 
>> Actually it's crazier than that. The concatenation of the current directory plus the relative path must be < MAX_PATH (approx.). Meaning, if you are 50 directories deep, a relative path starting with 50 `..\` still won't allow you to access C:\file.txt.
>> 
>
> Ouch. Ok, yea, this is pretty solid evidence that ALL usage of non-`\\?\` paths on Windows needs to be killed dead, dead, dead.
>
> If it were decided (not that I'm in favor of it) that we should be protecting developers from files named " a ", "a." and "COM1", then that really needs to be done on our end on top of mandatory `\\?\`-based access. Anyone masochistic enough to really WANT to deal with MAX_PATH and such is free to access the Win32 APIs directly.

+1

On Windows, every logical path provided to the std file functions should be properly converted to a physical path starting with that prefix.

Obviously this won't solve ALL Windows-specific problems, but that will AT LEAST remove a whole class of them.

On Thursday, 20 September 2018 at 19:49:01 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/19/2018 11:45 PM, Vladimir Panteleev wrote:
>> On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky (Abscissa) wrote:
>>> (Not on a Win box at the moment.)
>> 
>> I added the output of my test program to the gist:
>> https://gist.github.com/CyberShadow/049cf06f4ec31b205dde4b0e3c12a986#file-output-txt
>> 
>> 
>>> assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );
>> 
>> Actually it's crazier than that. The concatenation of the current directory plus the relative path must be < MAX_PATH (approx.). Meaning, if you are 50 directories deep, a relative path starting with 50 `..\` still won't allow you to access C:\file.txt.
>> 
>
> Ouch. Ok, yea, this is pretty solid evidence that ALL usage of non-`\\?\` paths on Windows needs to be killed dead, dead, dead.
>
> If it were decided (not that I'm in favor of it) that we should be protecting developers from files named " a ", "a." and "COM1", then that really needs to be done on our end on top of mandatory `\\?\`-based access. Anyone masochistic enough to really WANT to deal with MAX_PATH and such is free to access the Win32 APIs directly.

Decided to play around with this for a bit.  Made a "proof of concept" library:

https://github.com/marler8997/longfiles

It's just a prototype/exploration on the topic.  It allows you to include "stdx.longfiles" instead of "std.file" which will enable the conversion in every call, or you can import "stdx.longfiles : toLongPath" and use that on filenames passed to std.file.  There's also a test you can run

rund test/test_with_longfiles.d (should work)
rund test/test_without_longfiles.d (should fail)

NOTE: use "rund test/cleantests.d" to remove the files...I wasn't able to via the windows explorer program.

On Saturday, 22 September 2018 at 20:46:27 UTC, Jonathan Marler wrote:
> Decided to play around with this for a bit.  Made a "proof of concept" library:

I suggest using GetFullPathNameW instead of GetCurrentDirectory + manual path appending / normalization. It's also what CoreFX seems to be doing.