proposal: do not report hard links to one file as duplicates #172

New Issue

2026-11-11T01:06:00+01:00

clawbot commented

2026-11-11 01:06:00 +01:00

Proposal from the acceptance test (#164). It needs your decision before anyone builds it.

What is missing

Two names for one file (hard links) are reported as duplicates:

report lists them as a row.
trees counts them toward duplicate trees.
Both summaries add their size to the reclaimable total, although removing one name frees nothing.

README.md records this as an accepted limitation and tells the user to test each pair by hand with [ a -ef b ].

Example from the test: hard/original.bin and its hard link hard/link.bin came out as a report row, with 4000 bytes counted as reclaimable.

Where it bites: a backup made of hard-linked snapshots (rsync --link-dest, cp -al). Every unchanged file in every snapshot is reported as a duplicate, every snapshot directory as a duplicate tree, and the reclaimable total is several times the space the backup really takes.

Why a user expects it

A duplicate finder is used to free space, and these rows free none.
fdupes and jdupes leave hard links out unless -H is given.

What it would take

scan already reads each file's device and inode, to read hard links once. It would store both with the record: two new columns in the files table.
report would leave out a dupe that is the same file as its first.
trees would leave out a dupe tree whose every file is the same file as in first.
Neither total would count a file shared with the copy that is kept.
Trees that are only partly hard-linked need a decision that a spec would settle.

Your choices

Leave hard links out: build the above, after a spec you approve.
Keep the limitation: nothing changes, and the README keeps telling the user to test each pair.

Recommended: Leave hard links out. It is the one item in this test where the reports mislead by a large factor on a common kind of tree.

Model: fable-5-2

Proposal from the acceptance test (https://git.eeqj.de/sneak/sfdupes/issues/164). It needs your decision before anyone builds it. ## What is missing Two names for one file (hard links) are reported as duplicates: - `report` lists them as a row. - `trees` counts them toward duplicate trees. - Both summaries add their size to the reclaimable total, although removing one name frees nothing. `README.md` records this as an accepted limitation and tells the user to test each pair by hand with `[ a -ef b ]`. Example from the test: `hard/original.bin` and its hard link `hard/link.bin` came out as a `report` row, with 4000 bytes counted as reclaimable. Where it bites: a backup made of hard-linked snapshots (`rsync --link-dest`, `cp -al`). Every unchanged file in every snapshot is reported as a duplicate, every snapshot directory as a duplicate tree, and the reclaimable total is several times the space the backup really takes. ## Why a user expects it - A duplicate finder is used to free space, and these rows free none. - `fdupes` and `jdupes` leave hard links out unless `-H` is given. ## What it would take - `scan` already reads each file's device and inode, to read hard links once. It would store both with the record: two new columns in the `files` table. - `report` would leave out a `dupe` that is the same file as its `first`. - `trees` would leave out a `dupe` tree whose every file is the same file as in `first`. - Neither total would count a file shared with the copy that is kept. - Trees that are only partly hard-linked need a decision that a spec would settle. ## Your choices - **Leave hard links out**: build the above, after a spec you approve. - **Keep the limitation**: nothing changes, and the README keeps telling the user to test each pair. Recommended: **Leave hard links out**. It is the one item in this test where the reports mislead by a large factor on a common kind of tree. Model: fable-5-2

sneak was assigned by clawbot

2026-11-11 01:06:00 +01:00

clawbot referenced this issue

2026-11-11 01:07:59 +01:00

Acceptance test: use sfdupes end to end as a user, and list missing basics #164

sneak commented

2026-11-11 03:23:13 +01:00

yes, but paused until post-1.0. my use case doesn't involve hardlinks

clawbot commented

2026-11-11 03:24:04 +01:00

sneak (11 November, about 02:23 UTC): yes, but postponed until after 1.0; his use involves no hard links. Not worked before 1.0.

Model: opus-5-5

sneak (11 November, about 02:23 UTC): yes, but postponed until after 1.0; his use involves no hard links. Not worked before 1.0. Model: opus-5-5

sneak was unassigned by clawbot

2026-11-11 03:24:04 +01:00

clawbot added the needs-decision label 2026-11-11 14:10:24 +01:00

clawbot commented

2026-11-11 14:10:27 +01:00

No PR: sneak put this on hold until after 1.0 (comment above), and there is no 1.0 release yet.

Model: opus-5-5

No PR: sneak put this on hold until after 1.0 (comment above), and there is no 1.0 release yet. Model: opus-5-5

clawbot added post-1.0 and removed needs-decision labels 2026-11-11 14:10:59 +01:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/sfdupes#172