--unmatched-basename is (1) crashing and (2) misbehaving when hardlinks are part of the dataset

[intelfx]

While I was investigating hardlinked file handling for #614 (see comments) I encountered several issues with --unique-basenames.

version

• current rmlint develop (58d29ec1fbc6fae7359202778e148e3f3b096b88), v2.10.1-281-g58d29ec1
• a575d6ef2646c1fac1abaa6df79efecaa88e02d9 reverted
• gui/setup.py patched

problem 1 testcase

# mkdir dir1 dir2
# for n in {1..20}; do dd if=/dev/urandom of=dir1/file$n bs=1M count=1024; done
# cp -a --reflink=never dir1 -T dir2
# ln -f dir1/file20 dir2/file20
# rmlint -T df --unmatched-basename .
ERROR: Aborting due to a fatal error. (signal received: Segmentation fault)
ERROR: Please file a bug report (See rmlint -h)

This one can be fixed with 594121fa8252b31028781e774954e66905b83431.

problem 2 testcase

# mkdir dir1 dir2
# for n in {1..20}; do dd if=/dev/urandom of=dir1/file$n bs=1M count=1024; done
# cp -a --reflink=never dir1 -T dir2
# ln -f dir1/file20 dir2/file20
# ln -f dir1/file20 dir2/file20_1
# rmlint -T df -o pretty -o summary --unmatched-basename .
==> In total 43 files, whereof 0 are duplicates in 0 groups.
==> This equals 0 B of duplicates which could be removed.
==> 3 other suspicious item(s) found, which may vary in size.
==> Scanning took in total 0.635s.

Expected behavior: 1 group, dir1/file20 original, dir2/file20 original, dir2/file20_1 duplicate. Likewise with a group of just 2 suitable hardlinks (drop dir2/file20, it still won't see the group).

Basically, as I see it, --unique-basenames handling code does not consider hardlinks at all, only considering a single name for every inode.

[cebtenzzre]

I am aware of several issues with --unmatched-basename, on master at least. I'll have to confirm whether either of these are new to me, although I don't think I've seen it crash before.