You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you are running a version of Windows that exhibits the 260 character MAXPATH limit, eg, Windows 7, 8 or 10, you can use HashCheck's shell extension to Create Checksum File and it will work flawlessly even on files in paths greater than 260 characters. However, if you double-click the digest file just created, you will encounter an UNREADABLE error on files exceeding the 260 total path character limit.
This is a limit that has been overcome in Windows a long time ago, by utilizing "Unicode" APIs when handling file operations. The Create Checksum function is doing this correctly. The Verify Checksum function is doing this incorrectly. A simple unification of file access behavior should be in order.
The text was updated successfully, but these errors were encountered:
Thanks for posting, I'm looking to upgrade my 2014 version of Gurnec's HashCheck because I need long path support. Really hope that feature can be added to this.
This is also particularly an issue with anything Linux related such as Ext file systems or even just using the verifier directly on Linux via wine (because there has been a major lack of GUI-based options on Linux that support recursive directories).
If you are running a version of Windows that exhibits the 260 character MAXPATH limit, eg, Windows 7, 8 or 10, you can use HashCheck's shell extension to Create Checksum File and it will work flawlessly even on files in paths greater than 260 characters. However, if you double-click the digest file just created, you will encounter an UNREADABLE error on files exceeding the 260 total path character limit.
This is a limit that has been overcome in Windows a long time ago, by utilizing "Unicode" APIs when handling file operations. The Create Checksum function is doing this correctly. The Verify Checksum function is doing this incorrectly. A simple unification of file access behavior should be in order.
The text was updated successfully, but these errors were encountered: