file: make _wopen() and _open() able to handle long legacy DOS paths

[sergio-nsk]

Issue: #8361

Perl in C:\Program Files\Git\usr\bin supports long paths w/o any manifest or registry changes. Why not let curl support long paths.

BTW the solution offered by "5.13 long paths are not fully supported on Windows" in the known bugs does not work, because there is no way how to specify //?/ in file://. RFC 8089 excludes such paths \\?\ and \\.\. file://localhost///?/C:/foo or file://localhost/\\?\C:\foo are also invalid URLs.

[jay]

prepending \\?\ to a path disables all parsing of the path. like any forward slashes and .. will not be converted. you are assuming that any path starting with the drive letter and a colon will not need any interpretation

[nmoinvaz]

@jay that modified path is only passed into _open and _wopen. Are you seeing otherwise? As far as I can tell after it is used by those functions it is no longer used anywhere else.

[jay]

that modified path is only passed into _open and _wopen

I agree but I'm saying the logic is wrong. You can't assume that if a user specifies a path with a drive letter and colon that it is not going to need some interpretation. c:\foo/bar/../baz is not \\?\c:\foo/bar/../baz it is \\?\c:\foo\baz. you can't prepend \\?\ without first interpreting. Also IIRC \\?\ is only actually effective on the unicode W-suffixed api functions and crt w functions that wrap them (ie UNICODE/_UNICODE builds)

[sergio-nsk]

prepending \\?\ to a path disables all parsing of the path. like any forward slashes and .. will not be converted. you are assuming that any path starting with the drive letter and a colon will not need any interpretation

Right, it disables the path parsing, but it does not matter, the limitation PATH_MAX breaks the file opening before the parse result that can be less than PATH_MAX. Hence, the result is the same - unable to open a file.

The simple code with the existing 259 char path:

#include <fcntl.h>
#include <io.h>
#include <stdio.h>
#include <string.h>

void win_open(const char *path, const char *msg)  {
   int fh1 = _open( path, _O_RDONLY ); // C4996
   if(fh1 == -1) {
      printf("Open %s failed on file ", msg);
      perror("");
   } else {
      printf("Open %s succeeded on input file\n", msg);
      _close(fh1);
   }
}

int main(void) {
   const char *path259_l =   "\\\\?\\C:\\Work\\solid\\third_party\\curl\\tests\\log\\verylooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooongdir\\dir\\..\\verylooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooongfile3206.txt";
   const char *parsed259_l = "\\\\?\\C:\\Work\\solid\\third_party\\curl\\tests\\log\\verylooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooongdir\\verylooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooongfile3206.txt";

   win_open(path259_l + 4, "259 legacy");
   win_open(path259_l, "259 long");

   win_open(parsed259_l + 4, "259 parsed legacy");
   win_open(parsed259_l, "259 parsed long");
}

The output:

Open 259 legacy failed on file No such file or directory
Open 259 long failed on file Invalid argument
Open 259 parsed legacy succeeded on input file
Open 259 parsed long succeeded on input file

If the unparsed path in the argument exceeds 259 chars, it does not matter, neither that path, nor \\?\... path can be opened. So, \\?\ does not make it worse.

[sergio-nsk]

As for forward slashes, curl translates them to backward slashes before curlx_win32_open() call.

[jay]

Right, it disables the path parsing, but it does not matter, the limitation PATH_MAX breaks the file opening before the parse result that can be less than PATH_MAX. Hence, the result is the same - unable to open a file.

It does matter. I think it's wrong to prepend \\?\ without properly converting the path. Your logic assumes a long path (wcslen(filename_w) >= MAX_PATH) you can just prepend \\?\ and that is not necessarily true. Also IIRC there are still places in curl where we use PATH_MAX/MAX_PATH, as I mentioned in that other issue. You can't assume that all of libcurl code will successfully pass a long path to curlx_win32_open.

[sergio-nsk]

that is not necessarily true.

You can't assume that all of libcurl code will successfully pass a long path to curlx_win32_open.

Not necessarily true, right. I don't assume anything. I just made it better in some cases, and not worse in other cases.

file://localhost/c:/very-long-path and file:///c:/very-long-path now work and this is good for curl.

[bagder]

The new test fails in several windows CI jobs.

[sergio-nsk]

Windows builds don't seem to translate / to \ file paths. Will loot for the best solution, maybe just will just replace / with \ in the changed function. Weird, it worked locally at me.

[jay]

I'm proposing #13522 to address this issue with a normalization check and cover all the file functions that we wrap.

[sergio-nsk]

I will check #13522 in WinRT on Monday. Long paths are usual in WinRT.

[sergio-nsk]

Closing in favor of the other PR.