Feature Request: Option to include filename in output (-o filename.txt)

[lexterror]

It would be great if it could print the output for each individual file in a separate .txt file containing the hash!

Thank you!

[jonelo]

Interesting feature request, but what's wrong with one check file containing all information for performing a later integrity verification? Actually I am wondering what the benefit is to have the file system cluttered with hundreds or even thousands of small hash files? It could become also difficult to get rid of those hash files again if you don't need them anymore. Also, if you hash a folder where you only have read permissions, where to store those hash files then?

Please don't get me wrong, I just would like need to understand the actual use case and I believe this needs a bit of discussion or an enlightment so that I can see the benefit as well ;-)

[jonelo]

or maybe I completely misunderstood your feature request (which is very likely) ?

[lexterror]

Hi,

Your program is very powerful! I actually use quite often:

https://www.binaryfortress.com/HashTools/

It has this feature but only supports a limited amount of hash types that are kind of outdated. Its also able to recursively compare the individual file against the hash for that file making it really easy to test file integrity! You could try it out and see if you like it! I personally love it!

[lexterror]

Example:

-o *.sha3-512

This would recursively create a *.sha3-512 for every file!

myfile1.doc would have a myfile1.doc.sha3-512 file with the hash!

And then you could something like:

-check *

And it would then compare (recursively) any file with the *.sha3-512 of the same name!

And hopefully give an "ok" after each comparison!

To me this seems logical and of course a very fast way to test file integrity! I dont see a point in visually comparing a hash number unless you are double checking! Its practical and saves time!

[jonelo]

Thanks for elaborating on this issue.

Well, Jacksum already supports file integrity checking, and that is a very easy process actually.

1. Calculate the Message-Digest SHA3-512 of all files in the current working directory (.) and it's sub folders, and stores output to all-my-hashes.txt

jacksum -a sha3-512 -E hex -o all-my-hashes.txt .

2. Verify all hashes stored in the all-my-hashes.txt file, and find all new files that are being stored anywhere in the diretory tree below the current working directory.

jacksum -a sha3-512 -E hex -c all-my-hashes.txt .

Is it still on your wishlist to have a separate hash file for each hashed file?

[lexterror]

Its good enough for me! Thank you for your time! Its really a great program! Im always interested in new things! Thank you!

[Alepod]

@lexterror You could also use CMD's for command to achive same effect.

[lexterror]

Great! Thank you Alepod!

[jonelo]

Thanks folks. For just a few files the scripting idea would be an acceptable choice in order to cover that corner case.

Please let me elaborate why I don't like to code that use case in Jacksum, because there are good reasons. The advantages to have exactly one hash file (and not a hash file for each hash) are:

• it doesn't hurt data integrity of the existing file/folder structure, because we don't add additional files to the existing structure. In case of multiple hash files, it would actually hurt the data integrity of the existing file/folder structure, because we would add somthing that was not there before the calculation
• one file containing all hashes can be stored anywhere, it can be easily transferred, and a backup of the check file can be made easily as well. Achieving the same with many check files will be a heavy task.
• Determining the integrity of one hash file that contains all hashes is esay. You could make a backup of the file and/or calculate a hash value of the check file.
• all-my-hashes.txt (from the example above) can be removed very quickly if it is not needed anymore. If there are many hash files it will become very difficult to remove all of them. Also not to remove something by accident that we wanted to keep is risky.
• all-my-hashes.txt (from the examle above) can be easily transferred to a different computer in order to check file integrity on a remote copy. Not easily possible with multiple separate hash files.
• verification checks can be done on read-only file systems (again, because one hash file can be stored easily anywhere else). Not possible if you need to store the hash file in the same folder where the file is stored, because read-only file systems won't allow us to do that by definition.
• one file saves disk space. Hundreds or even thousands of hash files would consume much more space together, because each file (even if it is only a few bytes) consumes at least one block on many modern file systems. See also https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95
• with respect to I/O calls, both the creation process and the verification process with one hash file are being performed as fast as possible. It would take much longer to read hash files for each file, because the underlying OS would need to handle thousands of I/O open and close requests. Also one large hash file can be read much quicker than hundreds of small files, because in the first case full read buffers lead to good performance. The number of read calls would increase dramatically with many hash files.
• almost any serious message digest tool I am aware of on GNU/Linux and Unix derivates use one file to store hashes, none of those tools store hashes for each file separately

IMHO having separate hash files for each file is a bad design decision for a data integrity tool. And just because there is one Windows tool on the web that does it that way, does not necessarily mean that it is the right thing to do. Just my 0.02 Cents.

If there are any good reasons/use cases that I have ignored, please don't hesitate and fire away, and I am happy to think about it twice or even third times. For now, I just don't see any good reason to have separate hash files for each file hashed.

Thanks for reading, Johann

[lexterror]

Hi Jonelo!

I really don't mind using 1 file for storing hashes. I did notice that if the file structure isn't the same later that the command used to compare doesn't find certain files! It could be that I'm missing commands? It would be nice to be able to just check recursively even if the folder structure isn't the same! But it's no rush, it's really fantastic there are so many possibilities! Thank you! At the moment I have this comic book collection on my pc that uses a program called "Neeview". On Android I have the same collection but I'm using a program called "Tachiyomi" and it requires a different folder structure. I also read some description online a few years ago saying that it was a 'standard' to have '*.sha512' for example... It could be false advertising!

[lexterror]

Using the 1 file method: I think this would work for a new verify command:

[1] Recursively load into RAM the name of all the files (including files in subfolders) [2] Load into RAM all the file names listed in the "all-my-hashes.txt" [3] Filter out non matching file names [4] Compare the hashes for the file names left

*This could be a new verify command for non conforming folder structures