First, the criterion in rm_shred_group_update_status() that is responsible for hashing partially-hashed groups to the end is broken. It can never be fulfilled because group->head_files is always empty at this point, and even if it was not, head->digest is always NULL because that's what rm_shred_group_push_file() does.
The only reason why --hash-unmatched even works is because the --merge-directories condition above is broken as well and it always fires for all single-file groups. (Consequently, --hash-unmatched without --merge-directories is broken in develop.) However, the same bug also means that all unique files will always get hashed to the end if --merge-directories is set, thus making --hash-unmatched behave like --hash-uniques.
This function only works as designed if neither --hash-unmatched nor --hash-uniques is set, because in this case all single-file groups get filtered early by the rm_shred_group_qualifies() check.
The problem with
--hash-unmatchedis twofold.First, the criterion in
rm_shred_group_update_status()that is responsible for hashing partially-hashed groups to the end is broken. It can never be fulfilled becausegroup->head_filesis always empty at this point, and even if it was not,head->digestis always NULL because that's whatrm_shred_group_push_file()does.The only reason why
--hash-unmatchedeven works is because the--merge-directoriescondition above is broken as well and it always fires for all single-file groups. (Consequently,--hash-unmatchedwithout--merge-directoriesis broken in develop.) However, the same bug also means that all unique files will always get hashed to the end if--merge-directoriesis set, thus making--hash-unmatchedbehave like--hash-uniques.This function only works as designed if neither
--hash-unmatchednor--hash-uniquesis set, because in this case all single-file groups get filtered early by therm_shred_group_qualifies()check.Fixes #614.