[Feature Request] Long Path Support

[tERyceNzAchE]

HashCheck does not currently support long path names (> 260 characters).

[tERyceNzAchE]

Prefixing all path strings with \\?\ seems like a potential solution for Long Path Support.

Reference: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maxpath

For file I/O, the "?" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section Maximum Path Length Limitation.

[yjlin0224]

Any update here?

[idrassi]

Windows Explorer doesn't yet support long path names (cf https://theitbros.com/destination-path-too-long-error-when-movingcopying-a-file and look for "Win32 Long Paths GPO Not Working on Windows 10 File Explorer"). HashCheck is a shell extension dll loaded by Explorer so Explorer limitations apply to it.

The only possibility is to use \?\ as indicated by @tERyceNzAchE in the hope there will be no issue when Explorer passes the long path to us. I have doubts it will work because Explorer fails to open such paths but it is worth testing.

I will do some tests and let you know.

[ThomasCr]

Have your read: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

There is a regirtry key which should do the trick?

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

Maybe after also adding the app minifest with:

<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>

[NintendoManiac64]

Is there any update on this for the "elusive next version"? I nowadays use HashCheck on Linux via WINE (albeit only for reading existing checksums) and it seems to already handle long paths without issue as long as individual file names are less than 256 characters.

[idrassi]

Implemented for the HashCheck file I/O paths in 2.6.0.0 by commits 519e595 and 486618d. Failed file opens are retried with extended-length path prefixes (\?\ / \?\UNC). Explorer can still limit what it passes to shell extensions, but the HashCheck-side MAX_PATH open failure is addressed. Closing.