Overcome Windows 7 shell MAX_PATH limit

368 Views Asked by At

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?

2

There are 2 best solutions below

0
On

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.

0
On

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.