Verification Status, add more details for failed

[Ignis231]

I'd be interested to know when a file fails, what exactly has failed. I've had a couple of cases where files have had the last modified date change, but the file hash still remains the same. Things like this would be useful to identify.

[jonelo]

Thank you for your request! In Jacksum 4.0 I added additional options to manage the use case that you decribed more comfortable.

Preparation

Let's create an empty file called test.txt as the test file to demonstate the usage of Jacksum in this case.

On Microsoft Windows:

copy nul test.txt

On Linux and Unix/macOS:

touch test.txt

Check File Creation

In Jacksum 4.0 there is the "full style" output, and if specified, the output will contain hash value, timestamp, file size, and file name - everything we need:

jacksum40 --style full -O check.txt test.txt

For a shorter output in this discussion, we use full style, but disable the header:

jacksum40 --style full --no-header -O check.txt test.txt

The actual timestamp will be different on your computer, but on my computer, the output of the check.txt file is

a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a 2026-04-20T01:53:57.936+02:00 0 test.txt

Integrity Verification

Now, let's perform some checks.

At first we modify the timestamp, simply by touching the file again (see above for the command), so the file will have the same (empty) content (hashes are equal by definition in this case), but a different time stamp.

And now we perform the check by typing

> jacksum40 --style full -c check.txt
...
   FAILED  test.txt
           [timestamp expected: 2026-04-20T02:19:49.996+02:00, actual: 2026-04-20T02:23:11.324+02:00]
...

As you can see the expected and the actual timestamp are being printed. Note that in this case no hashing will occur, because hashing is expensive, and we know already that one of the expected values in the "check file" are different. In this case the easy to check time stamp. By default all information that can be found in the check file will be used for checks by Jacksum. What should be ignored for an check can be configured by the user. For example, let's ignore the timestamps:

> jacksum40 --style full --ignore-timestamps -c check.txt
...
       OK  test.txt
...

Now, it matches, because all the other critera match, except the timestamps which we have ignored.
If we change the content of the file (by adding some bytes for example), Jacksum will also detect the modification:

> echo test> test.txt
> jacksum40 --style full --ignore-timestamps -c check.txt
...
   FAILED  test.txt
           [filesize expected: 0, actual: 6]
...

Note hat also in this case, no hashing will occur since we know already that the expected integrity as described by the check file is hurt.
And if you only want to check whether the hashes match use this:

> jacksum40 --style full --ignore-timestamps --ignore-sizes -c check.txt
...
   FAILED  test.txt
...

Since we don't see any additional information blow the FAILED line, it means that the hash value failed.

BTW: You can achive the same with Jacksum 3.7 as well, but it is a little more work, because you have to specify --filesize, --timestamp, or --filesize to store those values to the checkfile. In 3.7 you cannot ignore values in the check file during verification, everything that is stored in the check file is taken into account and it has to match to get an OK. Jacksum 4.0 is more flexible in this case as shown above. Jacksum 4.0 is not released yet, but it has been already checked in at the main repo. I am going to release a supported binary in May.

Does that address your use cases?

[Ignis231]

Ah, yes, if it can list that it failed because the filesize didn't match for example, that would cover it. I take it that everything that didn't match is listed, not just the first thing that didn't?
Apologies I've only used hashgarten to integrate with this.
Is there any way I can add suggestion to hashgarten, it doesn't have a discussion tab on the git page?

[jonelo]

I’ve enabled the Discussions tab on the HashGarten project page. Feel free to ask questions, share ideas, or start a conversation there.

[jonelo]

Currently, the checks are designed to be efficient: if a basic attribute like the file size doesn't match, Jacksum skips further checks (like hashing) to save time, meaning an unexpected timestamp won't be flagged in that case.

However, I completely see why having that extra visibility could be useful. Sounds like a great feature request! Feel free to open an issue/idea for it. 😉