sfdupes scan /srv /srv/link/sub, with /srv/link a symlink to a directory, skips /srv/link/sub without a line. The walk of /srv does not follow the symlink, and the second operand is dropped as covered by the first. The records an earlier scan left for files under /srv/link/sub are then deleted.
Question: what should scan do with such an operand?
Recommended: walk it on its own, so its files are scanned once and keep their records. The README already says an operand the outer walk does not reach is walked on its own.
Or: skip it with a warning, as for an operand that is itself a symlink, and keep its records.
Model: opus-5-5
`sfdupes scan /srv /srv/link/sub`, with `/srv/link` a symlink to a directory, skips `/srv/link/sub` without a line. The walk of `/srv` does not follow the symlink, and the second operand is dropped as covered by the first. The records an earlier scan left for files under `/srv/link/sub` are then deleted.
Question: what should `scan` do with such an operand?
- Recommended: walk it on its own, so its files are scanned once and keep their records. The README already says an operand the outer walk does not reach is walked on its own.
- Or: skip it with a warning, as for an operand that is itself a symlink, and keep its records.
Model: opus-5-5
sneak
was assigned by clawbot2026-10-26 13:50:45 +01:00
Proposal, not yet a ruling: sneak asked in chat whether every path argument should be resolved to its real path, with symlinks followed, before the scan begins. If he says yes:
sfdupes scan /srv /srv/link/sub resolves the second argument to the directory the symlink points at; that directory is not under /srv, so it is scanned on its own and its files keep their records.
An argument that is itself a symlink is followed and scanned, instead of skipped with a warning as today.
Two arguments that resolve to the same directory, or one inside another, are scanned once.
Files are recorded and shown under their resolved paths, not the paths typed.
The .zfs rule (#142 (comment)) applies to the resolved path: a symlink into a .zfs directory is still never entered.
During the walk itself, symlinks are still not followed.
Nothing is built until he answers.
Model: opus-5-5
Proposal, not yet a ruling: sneak asked in chat whether every path argument should be resolved to its real path, with symlinks followed, before the scan begins. If he says yes:
- `sfdupes scan /srv /srv/link/sub` resolves the second argument to the directory the symlink points at; that directory is not under `/srv`, so it is scanned on its own and its files keep their records.
- An argument that is itself a symlink is followed and scanned, instead of skipped with a warning as today.
- Two arguments that resolve to the same directory, or one inside another, are scanned once.
- Files are recorded and shown under their resolved paths, not the paths typed.
- The `.zfs` rule (https://git.eeqj.de/sneak/sfdupes/issues/142#issuecomment-155846) applies to the resolved path: a symlink into a `.zfs` directory is still never entered.
- During the walk itself, symlinks are still not followed.
Nothing is built until he answers.
Model: opus-5-5
sneak
was unassigned by clawbot2026-10-26 16:47:36 +01:00
clawbot
self-assigned this 2026-10-26 16:47:36 +01:00
clawbot
removed their assignment 2026-10-26 16:48:34 +01:00
sneak
was assigned by clawbot2026-10-26 16:48:34 +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.
sfdupes scan /srv /srv/link/sub, with/srv/linka symlink to a directory, skips/srv/link/subwithout a line. The walk of/srvdoes not follow the symlink, and the second operand is dropped as covered by the first. The records an earlier scan left for files under/srv/link/subare then deleted.Question: what should
scando with such an operand?Model: opus-5-5
Proposal, not yet a ruling: sneak asked in chat whether every path argument should be resolved to its real path, with symlinks followed, before the scan begins. If he says yes:
sfdupes scan /srv /srv/link/subresolves the second argument to the directory the symlink points at; that directory is not under/srv, so it is scanned on its own and its files keep their records..zfsrule (#142 (comment)) applies to the resolved path: a symlink into a.zfsdirectory is still never entered.Nothing is built until he answers.
Model: opus-5-5