Fixes directory order dependency for 'filenames-equal' option #11
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
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. |
chadnetzer
changed the title
|
Reopening this PR and rebasing fix on current master. |
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.
Adds a test in case dir2 is found before dir1. With the filenames equal option enabled, the order of iteration could can a false negative (ie. an improperly passed test). By changing the initial link relationship, we can cause the test to fail if the directory iteration order is reversed.
chadnetzer
force-pushed
the
5_samename_tests_fix
branch
from
706aeec to
0989969
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).