'Overcome Windows 7 shell MAX_PATH limit
If context menu key that launches some executable exists in Windows registry and the "%1"
command line patrameter place holder is mentioned, the path this executable gets over GetCommandLine()
is limited to MAX_PATH
and in some cases Windows tries to make the short path name out of it.
Example:
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shell\showpath\command]
@="\"C:\\Program Files (x86)\\Utilities\\COMLINE.EXE\" \"%1\""
When the path is:
"\\\\SERVER\MediaFilder25\Philosophic\20220407 Draft thoughts. Questions without answers on the background of the torn Internet\20220407-1 Draft thoughts. Questions without answers on the background of the torn Internet\20220407 Draft thoughts. Questions without answers on the background of the torn Internet.ysssss"
COMLINE.EXE will get following:
"\\\\SERVER\MediaFilder25\39FC~1\202204~3\202204~2\20220407 Draft thoughts. Questions without answers on the background of the torn Internet.ysssss"
Nowadays string
length isn't limited. NTFS path depth isn't limited, too.
How to overcome this?
Solution 1:[1]
There is a way in registry to allow long paths, explained in this URL.
I comes down to the following registry key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001
In order to know your current value, you might do this:
reg query "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" | findstr "LongPathsEnabled"
It is limited to Windows 10, Version 1607, and Later, but your question is about Windows 7.
Solution 2:[2]
Windows 10, Version 1607 contains api-ms-win-core-path-l1-1-0.dll
.
There is a replica version of api-ms-win-core-path-l1-1-0.dll
that can manipulate long paths the way the Windows 10, Version 1607 it does.
Source code is available here: https://github.com/nalexandru/api-ms-win-core-path-HACK
I managed to compile it in Visual Studio 2012 after switching platform toolset to v110 and tested it successfully, for example, with Python 3.9 that relies now on this DLL.
I think, Windows 7 shell can't take advantage of using LongPathsEnabled
registry parameter out of the box, and applications should use this DLL directly (but in this case - why to use a DLL? we can build the proper function right into the application). My question was whether the shell can take advantage of it, and the answer is - "not yet!". It depends on shell itself.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | Paul |
Solution 2 |