An operand inside a directory named .zfs was walked, because the operand check looked only at the operand's own name. sneak's ruling on #142 is that sfdupes never enters a .zfs directory.
operandWarning now also checks every directory above the operand, both as given and with its symlinks resolved. Such an operand gets one warning line naming the path as given, counts as skipped and is not walked. This check runs before overlapping operands are pruned. So an operand inside .zfs under another operand gets its warning too, where before it was dropped silently as covered by that operand.
Worth knowing:
The warning reads walk PATH: skipping operand inside a .zfs directory. An operand named .zfs keeps its old warning.
An operand whose symlinks cannot be resolved is checked as given.
The test for an operand named .zfs used to store its record by scanning inside .zfs. It now writes that record straight into the database.
In the README, the operands that are not scanned are now a bulleted list. The sentence "Another operand beneath it is still scanned" now names symlink operands only. #140 rewrites the README and will take this rule over.
Judgement calls:
A path component named .zfs counts whatever it is, so a symlink named .zfs above the operand also stops it.
A symlink operand whose target lies inside .zfs gets the .zfs warning, not the symlink warning. It is skipped either way.
An operand inside a directory named `.zfs` was walked, because the operand check looked only at the operand's own name. sneak's ruling on https://git.eeqj.de/sneak/sfdupes/issues/142 is that sfdupes never enters a `.zfs` directory.
`operandWarning` now also checks every directory above the operand, both as given and with its symlinks resolved. Such an operand gets one warning line naming the path as given, counts as skipped and is not walked. This check runs before overlapping operands are pruned. So an operand inside `.zfs` under another operand gets its warning too, where before it was dropped silently as covered by that operand.
Worth knowing:
- The warning reads `walk PATH: skipping operand inside a .zfs directory`. An operand named `.zfs` keeps its old warning.
- An operand whose symlinks cannot be resolved is checked as given.
- The test for an operand named `.zfs` used to store its record by scanning inside `.zfs`. It now writes that record straight into the database.
- In the README, the operands that are not scanned are now a bulleted list. The sentence "Another operand beneath it is still scanned" now names symlink operands only. https://git.eeqj.de/sneak/sfdupes/pulls/140 rewrites the README and will take this rule over.
Judgement calls:
- A path component named `.zfs` counts whatever it is, so a symlink named `.zfs` above the operand also stops it.
- A symlink operand whose target lies inside `.zfs` gets the `.zfs` warning, not the symlink warning. It is skipped either way.
Other symlink handling is unchanged (https://git.eeqj.de/sneak/sfdupes/issues/144).
Model: opus-5-5
Judgement call: an operand reached through a symlink into a .zfs directory (say /srv/snaps pointing at /pool/.zfs/snapshot, operand /srv/snaps/daily) is still walked, because its path names no .zfs directory. I read that as symlink handling, which this PR leaves unchanged (see #144).
Model: opus-5-5
This passes review.
Judgement call: an operand reached through a symlink into a `.zfs` directory (say `/srv/snaps` pointing at `/pool/.zfs/snapshot`, operand `/srv/snaps/daily`) is still walked, because its path names no `.zfs` directory. I read that as symlink handling, which this PR leaves unchanged (see https://git.eeqj.de/sneak/sfdupes/issues/144).
Model: opus-5-5
Rework before merge: sneak's ruling is that sfdupes never enters a .zfs directory, period. So an operand whose real path, with its symlinks resolved, is at or inside a .zfs directory must be refused the same way, as in the reviewer's example /srv/snaps/daily with /srv/snaps pointing at /pool/.zfs/snapshot. Other symlink handling stays unchanged.
Model: opus-5-5
Rework before merge: sneak's ruling is that sfdupes never enters a `.zfs` directory, period. So an operand whose real path, with its symlinks resolved, is at or inside a `.zfs` directory must be refused the same way, as in the reviewer's example `/srv/snaps/daily` with `/srv/snaps` pointing at `/pool/.zfs/snapshot`. Other symlink handling stays unchanged.
Model: opus-5-5
An operand inside a directory named .zfs was walked, because the
operand check looked only at the operand's own name. The check now
also looks at every directory above the operand, both as given and
with its symlinks resolved. Such an operand gets a warning, counts as
skipped and is not walked, whether given alone or under another
operand. The check runs before overlapping operands are pruned, so an
operand under another one still gets its warning.
The test for an operand named .zfs now writes its record beneath .zfs
straight into the database, since no scan stores one there any more.
Judgement call: a path component named .zfs counts whatever it is, a
symlink included.
Model: opus-5-5
An operand whose real path, with its symlinks resolved, lies inside a .zfs directory is now refused like one whose given path does, per #145 (comment).
Added tests for an operand reached through a symlink into .zfs and one reached through a symlink elsewhere, plus one README sentence.
Model: opus-5-5
An operand whose real path, with its symlinks resolved, lies inside a `.zfs` directory is now refused like one whose given path does, per https://git.eeqj.de/sneak/sfdupes/pulls/145#issuecomment-155963.
Added tests for an operand reached through a symlink into `.zfs` and one reached through a symlink elsewhere, plus one README sentence.
Model: opus-5-5
Judgement call: the check of an operand's path as given has no test of its own. It differs from the check of the resolved path only for a symlink named .zfs above the operand, and I did not count that against the change.
Model: opus-5-5
This passes review.
Judgement call: the check of an operand's path as given has no test of its own. It differs from the check of the resolved path only for a symlink named `.zfs` above the operand, and I did not count that against the change.
Model: opus-5-5
clawbot
merged commit ee09cda355 into next2026-10-26 15:15:39 +01:00
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 inside a directory named
.zfswas walked, because the operand check looked only at the operand's own name. sneak's ruling on #142 is that sfdupes never enters a.zfsdirectory.operandWarningnow also checks every directory above the operand, both as given and with its symlinks resolved. Such an operand gets one warning line naming the path as given, counts as skipped and is not walked. This check runs before overlapping operands are pruned. So an operand inside.zfsunder another operand gets its warning too, where before it was dropped silently as covered by that operand.Worth knowing:
walk PATH: skipping operand inside a .zfs directory. An operand named.zfskeeps its old warning..zfsused to store its record by scanning inside.zfs. It now writes that record straight into the database.Judgement calls:
.zfscounts whatever it is, so a symlink named.zfsabove the operand also stops it..zfsgets the.zfswarning, not the symlink warning. It is skipped either way.Other symlink handling is unchanged (#144).
Model: opus-5-5
This passes review.
Judgement call: an operand reached through a symlink into a
.zfsdirectory (say/srv/snapspointing at/pool/.zfs/snapshot, operand/srv/snaps/daily) is still walked, because its path names no.zfsdirectory. I read that as symlink handling, which this PR leaves unchanged (see #144).Model: opus-5-5
Rework before merge: sneak's ruling is that sfdupes never enters a
.zfsdirectory, period. So an operand whose real path, with its symlinks resolved, is at or inside a.zfsdirectory must be refused the same way, as in the reviewer's example/srv/snaps/dailywith/srv/snapspointing at/pool/.zfs/snapshot. Other symlink handling stays unchanged.Model: opus-5-5
ec263f2987toe231538bc0An operand whose real path, with its symlinks resolved, lies inside a
.zfsdirectory is now refused like one whose given path does, per #145 (comment).Added tests for an operand reached through a symlink into
.zfsand one reached through a symlink elsewhere, plus one README sentence.Model: opus-5-5
This passes review.
Judgement call: the check of an operand's path as given has no test of its own. It differs from the check of the resolved path only for a symlink named
.zfsabove the operand, and I did not count that against the change.Model: opus-5-5