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
So, I've been asking a number of devs to include compatibility for reading and generating hash digest files (ie, .sha512) which include optional filesize along with the hash and the optional filename. The filesize is included as non-commented data, wedged between the hash and the filename with normal space delimiting.
Since the format of hash digests are validated anyway to determine whether or not the filename is being included, it's not that big of a deal to validate each line for the presence of filesize info as well. The added benefit of doing so permits software to validate hash digests and discover if files have been renamed or moved (or both) and to heal/repair the hash digest with the new filename or path.
As I understand it, the current formats being validated for are:
(I will admit I don't fully understand the history behind the "space-astrisk-path" and "double_space-path" formats, nor do I know if you also validate for the sloppy "single_space-path" form as well.)
I don't think validating for this added filesize format should break anything. And if you're willing, it would be totally awesome if OpenHashTab could also generate these hash digests as well, and maybe even perform those extra functions I mentioned about discovering renamed files and repairing digests.
So far VoidTools Everything supports this extended format, HashCheck has promised to add it, and RHash allows it as a user-defined format. I've also just asked RapidCRC-Unicode to consider the same.
The text was updated successfully, but these errors were encountered:
So, I've been asking a number of devs to include compatibility for reading and generating hash digest files (ie, .sha512) which include optional filesize along with the hash and the optional filename. The filesize is included as non-commented data, wedged between the hash and the filename with normal space delimiting.
Since the format of hash digests are validated anyway to determine whether or not the filename is being included, it's not that big of a deal to validate each line for the presence of filesize info as well. The added benefit of doing so permits software to validate hash digests and discover if files have been renamed or moved (or both) and to heal/repair the hash digest with the new filename or path.
As I understand it, the current formats being validated for are:
I'd like to see the inclusion of:
(I will admit I don't fully understand the history behind the "space-astrisk-path" and "double_space-path" formats, nor do I know if you also validate for the sloppy "single_space-path" form as well.)
I don't think validating for this added filesize format should break anything. And if you're willing, it would be totally awesome if OpenHashTab could also generate these hash digests as well, and maybe even perform those extra functions I mentioned about discovering renamed files and repairing digests.
So far VoidTools Everything supports this extended format, HashCheck has promised to add it, and RHash allows it as a user-defined format. I've also just asked RapidCRC-Unicode to consider the same.
The text was updated successfully, but these errors were encountered: