3

I have trouble here using fopen to open files which have paths longer than the 260 characters supported by Windows natively.

I found out about the prefix \\\\?\\ which I need to put in front of the path to be able to handle the file.

My question is: Is this still valid in combination with fopen? I have still trouble to open the files, but I do not find information about it. My paths look like:

\\\\?\\C:\\Deposit\\Source\\Here_Comes_Now_A_List_Of_Many_Subdirs_And_A_Long_File_Name

I am not able to use the Windows API due to the requirement to write a cross-platform tool.

Lundin
  • 195,001
  • 40
  • 254
  • 396
Rick-Rainer Ludwig
  • 2,371
  • 1
  • 26
  • 42
  • It's '\\?\' you are missing a '\'. See: http://msdn.microsoft.com/en-us/library/aa365247%28v=vs.85%29.aspx#maxpath Especiall the part about Win32 namespace is of relevance to your problem. It tells that if that identifier is prepended the IO functions will pass the path forward to the driver directly. – RedX Jul 26 '11 at 12:05
  • No, it was StackOverflows' editor. I corrected it. I needed to escape the backslashes. Sorry, my mistake. – Rick-Rainer Ludwig Jul 26 '11 at 12:07
  • "[...]because the file system treats path and file names as an opaque sequence of WCHARs" from RedX' link. My guess is that it will only work with e.g. _wfopen.. – user786653 Jul 26 '11 at 12:19
  • @Rick: what platform are you testing on? My tests with Win7 x64 indicate that `fopen("\\\\?\\c:\\a-very-long-pathname", "r")` works fine - I wonder if MS has removed the limitation on `CreateFileA()` in Vista or Win7? – Michael Burr Jul 26 '11 at 20:23
  • I use a WinXP SP3. I will check this on a computer of a peer. – Rick-Rainer Ludwig Jul 27 '11 at 12:14

2 Answers2

1

Just to update with the current state: I'm just quoting https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#enable-long-paths-in-windows-10-version-1607-and-later:

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from common Win32 file and directory functions. However, you must opt-in to the new behavior. To enable the new long path behavior, both of the following conditions must be met: ...

And it is:

1. Having <longPathAware>true</longPathAware> in your application manifest (it was not default in my C++ Visual Studio project). My manifest file looks like this:

<assembly>
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
      <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
  </application>
</assembly>

and I have added it into Project Options -> Manifest Tool -> Input and Output -> Additional manifest files in my C++ Visual Studio project.

2. Enabled long paths in Windows (this can be done through registry (in item Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled by setting to 1) or Microsoft says that in Local Group Policy (item Computer Configuration -> Administrative Templates -> System -> Filesystem -> Enable Win32 long paths) - but this does not work for me).

Having both the above configured, you can simply use FILE *f = fopen("../my-very-long-path/my-file.txt") without any limitations (e.g. relative dirs and / with \ replacement work).

Jarek C
  • 1,077
  • 6
  • 18
0

You could work around this limitation in a cross-platform way with conditional compilation:

#ifdef WIN32
     myFile = _wfopen( ... )
#else
     myFile = fopen( ... )
#endif

I think any non-trivial cross-platform project will have to do this somewhere, or else use a library (like SDL) that does.

JPL
  • 74
  • 2
  • According to documentation _wfopen() behaves like fopen beside using wide-chars ( https://learn.microsoft.com/de-de/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170 ) – Jesko Oct 11 '22 at 02:50