An operand under another operand was dropped as covered by it even when a directory between the two was named .zfs or was a symlink. The walk of the outer operand never enters a .zfs directory and never follows a symlink. So the files under the inner operand were not scanned, no line said so, and their records were deleted.
walkReaches now checks each directory between the two operands for both cases, beside the default-exclude check. It applies the walk's own tests: the name .zfs, and an lstat that finds a symlink. pruneRoots then keeps the inner operand and walks it on its own.
Worth knowing:
Only directories below the outer operand count. A symlink or .zfs directory above both operands changes nothing, and a test covers that.
An inner operand that is itself a symlink or a .zfs directory is still dropped before pruning, as before.
The README change is limited to the one sentence on nested operands, now a short list. #140 rewrites the README and will take this rule over.
Judgement call: the new constant zfsDirName replaces the .zfs literal in operandWarning and subdirJob too, because the linter rejects a third copy.
An operand under another operand was dropped as covered by it even when a directory between the two was named `.zfs` or was a symlink. The walk of the outer operand never enters a `.zfs` directory and never follows a symlink. So the files under the inner operand were not scanned, no line said so, and their records were deleted.
`walkReaches` now checks each directory between the two operands for both cases, beside the default-exclude check. It applies the walk's own tests: the name `.zfs`, and an lstat that finds a symlink. `pruneRoots` then keeps the inner operand and walks it on its own.
Worth knowing:
- Only directories below the outer operand count. A symlink or `.zfs` directory above both operands changes nothing, and a test covers that.
- An inner operand that is itself a symlink or a `.zfs` directory is still dropped before pruning, as before.
- The README change is limited to the one sentence on nested operands, now a short list. https://git.eeqj.de/sneak/sfdupes/pulls/140 rewrites the README and will take this rule over.
Judgement call: the new constant `zfsDirName` replaces the `.zfs` literal in `operandWarning` and `subdirJob` too, because the linter rejects a third copy.
Closes https://git.eeqj.de/sneak/sfdupes/issues/142
Model: opus-5-5
An operand under another was dropped as covered by it even when a
directory between them was named .zfs or was a symlink. The walk of
the outer operand enters neither, so the files under the inner operand
went unscanned and their records were deleted. walkReaches now reports
such an operand as not reached, so pruneRoots keeps it and walks it on
its own. README lists both cases with the others.
Judgement call: the new constant zfsDirName replaces the .zfs literal
in operandWarning and subdirJob too, because goconst rejects a third
copy.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
An operand under another operand was dropped as covered by it even when a directory between the two was named
.zfsor was a symlink. The walk of the outer operand never enters a.zfsdirectory and never follows a symlink. So the files under the inner operand were not scanned, no line said so, and their records were deleted.walkReachesnow checks each directory between the two operands for both cases, beside the default-exclude check. It applies the walk's own tests: the name.zfs, and an lstat that finds a symlink.pruneRootsthen keeps the inner operand and walks it on its own.Worth knowing:
.zfsdirectory above both operands changes nothing, and a test covers that..zfsdirectory is still dropped before pruning, as before.Judgement call: the new constant
zfsDirNamereplaces the.zfsliteral inoperandWarningandsubdirJobtoo, because the linter rejects a third copy.Closes #142
Model: opus-5-5
no! this is wrong.
Pull request closed