akaihola
Fixes directory order dependency for 'filenames-equal' option
With samename option enabled, possible matching hardlinks could be skipped depending on the directory iteration order and existing hardlink status of files. This was causing actual failure of test_hardlink_tree_filenames_equal() on some systems.
This seems like a minimum-change fix to fix the problem in issue #5, and allow the "filenames-equal" option to behave a bit more like expected.
Note that there is really a policy decision required longer term, as to how the "filenames-equal" option should behave when files have existing hard-links. As it is, since not all the matching files will be linked together in the end, existing hard-links between identical files with different basenames, will not necessarily be preserved (perhaps that is desired). A longer term project might be to decide what the behavior for existing hardlinks should be, and make that fully consistent (is could require a fair amount of code restructure, though).
I added a test that exercises this bug by setting up the initial link relationship in reverse order. Ie. it adds a test which links dir2/name1.ext to dir1/link before running the algorithm with --filenames-equal set.
This PR fixes the bug, which means both tests succeed. The bug can be demonstrated by cherry-picking only the commit with the added test, causing one of the two filenames equal tests to fail.