fix data-loss issue with replays w/o checksums

[vassilit]

Closes: #672

See bug details in #672 (comment).

This is just a bugfix, but I feel we could fix a bit more, although I'm not sure if that wouldn't introduce a regression. I haven't checked all the consumers of file->digest.

In replay.c we do:

    file->digest = rm_digest_new(RM_DIGEST_EXT, 0);
[...]
    /* Fake the checksum using RM_DIGEST_EXT */
    JsonNode *cksum_node = json_object_get_member(object, "checksum");
    if(cksum_node != NULL) {
        const char *cksum = json_object_get_string_member(object, "checksum");
        if(cksum != NULL) {
            rm_digest_update(file->digest, (unsigned char *)cksum, strlen(cksum));
        }
    }

I would do instead:

    file->digest = NULL;
[...]
    /* Fake the checksum using RM_DIGEST_EXT */
    JsonNode *cksum_node = json_object_get_member(object, "checksum");
    if(cksum_node != NULL) {
        const char *cksum = json_object_get_string_member(object, "checksum");
        if(cksum != NULL) {
            file->digest = rm_digest_new(RM_DIGEST_EXT, 0);
            rm_digest_update(file->digest, (unsigned char *)cksum, strlen(cksum));
        }
    }

And reintroduce checks for file->digest == NULL ; that would avoid pointless allocations.
Another way to be safe would be to check for file->inode to confirm that they belong to the same group.
Are hardlinks the only situation when rmlint does not generate checksums ?

PS: @sahib if you still follow this repository, the bird theme is nice. It's a change from the overly formal naming in code of other projects :)

[RayOei]

I would suggest to move this to its own issue as a future improvement, so it doesn't get forgotten?