On 09/19/2018 01:49 PM, Neia Neutuladh wrote:
> On Wednesday, 19 September 2018 at 08:54:42 UTC, Vladimir Panteleev wrote:
>> BTW, something follows from the above:
>>
>> write(`C:\` ~ (short path) ~  `con`) will fail
>>
>> but:
>>
>> write(`C:\` ~ (long path) ~ `con`) will succeed.
>>
>> This is just one issue I've noticed... there's probably more lurking.
> 
> Also, according to the internet:
> 
> write(chainPath(shortDirectory, "A "), "Win32 API strips trailing space");
> readText(chainPath(shortDirectory, "A")); // Win32 API strips trailing space
> 
> But:
> write(chainPath(longDirectory, "A "), "Win32 API strips trailing space");
> readText(chainPath(longDirectory, "A")); // File not found
> 
> write(chainPath(shortDirectory, "A."));  // fails
> write(chainPath(longDirectory, "A."));  // succeeds
> 

Ok, excellent, now we're getting somewhere! :) Based on these actual concrete examples, yes, I can now grant that converting paths that are past the limit would indeed cause subtly different behaviour.

So clearly this needs to be an all-or-nothing deal...

> This is why we should use the exact same behavior in all cases. Always use `\\?\` or never use it.

Yup.

> Since Windows path handling is weird by default, I'd prefer always using `\\?\`. It's overhead, but not a huge amount of additional overhead compared to filesystem manipulation.

My thoughts, exactly.

I'll also point out that this applies to user-code, too. Ie, with Phobos as it currently stands, user code has three options:

1. Never use `\\?\` and any time they compile their code on Windows, they must always be acutely aware of, and plan for, all of the fun little quirks of the Win33 file APIs.

2. Be *aware* of `\\?\` and always use it any time they compile their code on Windows (and always remember use longPath() or some such for all file operations when working on a cross-platform codebase).

3. Sometimes use `\\?\` and sometimes don't, and then deal with the fun little inconsistencies that creates.

I think ALL those options look really bad, but #2 seems the least terrible. But gee, wouldn't it be nice if we could just relieve that stupid burden on everybody of selecting and following #2? In the rare case where "doing the safe/correct thing by default" isn't good enough, there'd be nothing stopping anyone from calling the platform API directly if they really, really need to.

Opt-out is for safe, reliable, consistent things.
Opt-in is for difficult, tricky, dangerous things.
Not the other way around.

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.

On 09/19/2018 07:04 AM, Vladimir Panteleev wrote:
> On Wednesday, 19 September 2018 at 05:49:41 UTC, Nick Sabalausky (Abscissa) wrote:
>> 2. Detect and reject any non-\\?\ path longer than MAX_PATH-12 bytes[5].
> 
> This is not a good criteria: relative paths whose pointing to objects whose absolute path exceeds MAX_PATH will fail, too. So, it looks like Phobos would need to expand relative paths unconditionally.
> 

I'm not sure I'm quite following you. Is this what you mean?:

string dir = ...; // Such that...
assert( dir.isRelativePath );
assert( dir.length < MAX_LENGTH-12 );
assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );

// ??? This *currently* goes BOOM on Windows
// ??? installations with MAX_LENGTH restriction active?
rmdir(path);

(Not on a Win box at the moment.)

On 09/19/2018 11:23 PM, Nick Sabalausky (Abscissa) wrote:
> 
> rmdir(path);

Obviously meant "rmdir(dir);" here. Editing mishap.

On Thursday, 20 September 2018 at 03:23:36 UTC, Nick Sabalausky (Abscissa) wrote:
> I'm not sure I'm quite following you. Is this what you mean?:
>
> string dir = ...; // Such that...
> assert( dir.isRelativePath );
> assert( dir.length < MAX_LENGTH-12 );
> assert( dir.toAbsolutePath.length > MAX_LENGTH-12 );
>
> // ??? This *currently* goes BOOM on Windows
> // ??? installations with MAX_LENGTH restriction active?
> rmdir(path);
>
> (Not on a Win box at the moment.)

Correct.

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 :)

On Thursday, 20 September 2018 at 03:15:20 UTC, 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.

Dear lord Windows is terrible. Can we just deprecate it?

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.

On Thursday, 20 September 2018 at 02:48:06 UTC, Nick Sabalausky (Abscissa) wrote:
> On 09/19/2018 02:33 AM, Jonathan Marler wrote:
>> 
>> What drives me mad is when you have library writers who try to "protect" you from the underlying system by translating everything you do into what they "think" you're trying to do.
>
> 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. Bonus points if they're doing it mainly to help with my C++-standard premature optimizations.
>
> If I actually want to deal with platform-specific quirks, then I'll use the platform's API directly. (And then I'll beat myself with a brick, just for fun.)

+1

A cross-platform library has to be designed to operate in the same way on each supported platform, even if this means that it's harder to implement on some platform, or that some platforms will need more complicated implementations.

That's the whole point of this "HAL" approach.

On Thursday, 20 September 2018 at 03:15:20 UTC, 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.

*Windows Explorer* prevents you from creating a folder or file whose name STARTS with spaces. It trims them automatically, whether you want it or not.

So it's NOT a surprise that *Windows Explorer* (!) has problems if you use it on such files which were created manually.

But obviously, *Windows* OS doesn't prevent you to create them through scripts and applications...