-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for long paths #70
Comments
It's a windows limitation. most programs stop working correctly past that point for the same reason. there is a setting that extends the limit but breaks back compat, but I don't remember what it's called |
P.S. also see: #30 |
The setting you mean probably is HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem DWORD "LongPathsEnabled" Value: 1 however this does not work for HashCheck. Maybe this is a limitation for extensions of the Explorer Properties. The basic issue is that HashCheck does silently fail, either failing at rading the file and ending with "a of b files hashed" where a < b or even ignoring the existence of a file (b < real number of files n). I think: a< b happens, if the path to a file is too long, but the folder path is not (hence HashCheck can read the contents of the folder but not access the files within) b<n happens when the path of the folder is too long and HashCheck cannot determine the number of files. THIS is a real problem, as you would not notice it in a real world case. even worse: This silent fail also happens, if a file is locked (Try to hash pagefile.sys for example) |
Does not generate or verify hashes when path is longer than 260 characters. Is possible to add the feature without breaking backwards compatibility?
The text was updated successfully, but these errors were encountered: