Long path support in OPEN

[KUDELA__László]

Hello All,

I have been trying to use the long path (longer than 260 characters) support feature that is available on Windows 10 starting from version 1607. According to the guide in Microsoft docs, to enable this, two things are needed:

• Set a registry key
• Include the appropriate  section in the application manifest

I did these two things, but unfortunately, opening a file with OPEN(UNIT=1, FILE={some_long_filename}, IOSTAT=ierr) does not seem to accept the long path. This is what happens:

• As expected, if my application is missing the manifest, ierr from OPEN contains an error code. This seems to be ok.
• If the application includes the manifest file, OPEN(…) works without an error, but the actual path length gets truncated to 260 characters. For example, if I want to write a file to "C:\foo\bar\{some_long_path}\written_by_fortran.txt", OPEN might open a file whose name is "C:\foo\bar\{some_long_path}\written_", or whatever is left after truncating to 260 chars.

After analyzing the problem with ProcessMonitor, I figured out that OPEN will invoke CreateFileA(…) from the Windows API, which is the function that is not supposed to accept long paths. Therefore, I opted for the USEROPEN feature of OPEN, which allows to use a customized function for file opening. I implemented a custom opener, lets call it "uopen". Inside uopen, I call CreateFileW, which, according to the docs is the version that should accept long paths. Now, the problem is that at the entry to "uopen" the path is already truncated, exactly to 260 characters (not including the drive letter).

After playing with ProcessMonitor again, I figured that the following chain of calls happen:

1. OPEN statement invokes for_open
2. for_open invokes fq_settextposition
3. fq_settextposition calls uopen, my customized open function

So, I guess that either for_open or fq_settextposition truncates the path to 260 characters, before calling uopen. 

For the sake of completeness, I tried to prepend my paths with "\\?\" -> did not help, the path got truncated again, but no error code was produced. I also tried just simply putting "?" before the path, this did not help either, although at least an error code was returned.

I am attaching a picture of the stack that I see a small CMake project with a comparison to C and C++, where long paths seem to work.

Is there anything else I could try? Is there maybe some "hidden feature", like a switch or environment variable to deal with this sort of issue?

Here is the info about my system:

• Windows 10, Version 1803
• IFORT Version 19.0.4.228 Build 20190417
• VC compiler Version 19.16.27031.1 for x64

Thanks for the help!

EDIT: CMake project attached.

[Steve_Lionel]

You're doing very well so far in your analysis - congratulations. My advice is to have your USEROPEN routine get the filename from other than the passed-in filename, such as a module variable you set before doing the OPEN. You can then put in anything you want for the FILE=. (This might interfere with INQUIRE by FILE, but my guess is you're not using that.)