Skip to content
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

[Enhancement] Ability to recursively hash folders, sub-folders, and their contents #143

Open
NintendoManiac64 opened this issue Jun 2, 2022 · 2 comments

Comments

@NintendoManiac64
Copy link

NintendoManiac64 commented Jun 2, 2022

As it currently stands, GtkHash is not able to hash the contents of folders and/or sub-folders, only multiple individual files. Including this would then replicate the functionality that exists in "HashCheck Shell Extension" (which I personally have used for over a decade now...but as of a few months ago, I am no longer using Windows on my primary PC).

And, just like how one can do a right-click -> "open with" and open a file directly in GtkHash and have it automatically hashed, one should ideally be able to do the same sort of right-click -> "open with" on a folder and have it opened in in GtkHash directly and subsequently automatically start hashing its contents (though, at least on Linux Mint 20.3, the right-click -> "open with" is only present within Thunar or Nemo windows and isn't available on the desktop itself).

Also, as mentioned in my other issue, "HashCheck Shell Extension" actually works via WINE 7.x, at least for reading/verifying/processing already-existing checksum files.

Here are some examples of the format used by "HashCheck Shell Extension" when folders and sub-folders are involved:

CRC32

1st folder name goes here\1st sub-folder name goes here\even more test 1.txt    72595d96
1st folder name goes here\1st sub-folder name goes here\even more testing 1.txt 54320b9a
1st folder name goes here\more test 1.txt                                       768115b2
1st folder name goes here\more testing 1.txt                                    dbde7a49
2nd folder name goes here\2nd sub-folder name goes here\even more test 2.txt    eb500c2c
2nd folder name goes here\2nd sub-folder name goes here\even more testing 2.txt cd3b5a20
2nd folder name goes here\more test 2.txt                                       ef884408
2nd folder name goes here\more testing 2.txt                                    42d72bf3
test.txt                                                                        d87f7e0c
testing.txt                                                                     e8f35a06

SHA1

0c798ca2b42f4f3a592496d2d398791fcd6a5280 *2nd folder name goes here\2nd sub-folder name goes here\even more test 2.txt
b1464e328d5dbea89963036971d5066bb8abc09b *2nd folder name goes here\2nd sub-folder name goes here\even more testing 2.txt
8d15b5f25464c36e81edba7cd448d5a7f3548745 *2nd folder name goes here\more test 2.txt
4136de17281364aefebb1c63d4e14385e7a2b18e *2nd folder name goes here\more testing 2.txt
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3 *test.txt
dc724af18fbdd4e59189f5fe768a5f8311527050 *testing.txt
2bd5500181fbeaa0a15376e74946151362d6b9fa *1st folder name goes here\1st sub-folder name goes here\even more test 1.txt
f243bc079c2fa4857b571d27c868852f90469f84 *1st folder name goes here\1st sub-folder name goes here\even more testing 1.txt
9684340814709b96633b6fcd8c32f81820bf820d *1st folder name goes here\more test 1.txt
ed687fe81e4cece452c237e6bc7c4232f854ded7 *1st folder name goes here\more testing 1.txt

Do note that, despite the presence of asterisks in the SHA1 example, they seem to actually be optional and it similarly works without issue even if the asterisks are not present. For reference, not having an asterisk is how GtkHash currently behaves when saving checksum files and therefore, in theory, that aspect doesn't actually require any change.

EDIT: It seems like GtkHash only supports reading checksum files that use a normal slash as a directory separator rather than also a backslash. That's a bit of an issue since the slew of Windows software for make checksum files create paths with backslashes (and obviously they're the only solution at this time for GUI-based checksum creation supporting recursive directories).

@KelumPerera
Copy link

KelumPerera commented Oct 7, 2022

Much needed a feature as more often we need to see the hash values of the full content in subfolders too.

Also be great if we can see the file size, last updated & file created DateTime stamps on the result list, with the ability to sort the list according to any of the list headers.

@NintendoManiac64
Copy link
Author

NintendoManiac64 commented Oct 7, 2022

Also be great if we can see the file size, last updated & file created DateTime stamps on the result list, with the ability to sort the list according to any of the list headers.

As nice as that would be, I question if that'd be able to be implemented without breaking compatibility with other software that can read .sfv and .sha1 checksum files.

EDIT: Unless this information was stored in the equivalent of a comment? Other software seem to treat lines beginning with ; as meaning a comment inside of checksum files, but GtkHash seems to not support this and it just results in GtkHash being unable to read the checksum file altogether.

@NintendoManiac64 NintendoManiac64 changed the title [Enhancement] Ability to hash folders, sub-folders, and their contents [Enhancement] Ability to recursively hash folders, sub-folders, and their contents Feb 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants