proposal: hash a file again when its mtime moved back, not only forward #176

New Issue

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

clawbot commented

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

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

What is missing

scan reads a recorded file again only when its size differs or its mtime is newer than recorded. A file replaced by another of the same size with an older mtime is never read again, however many scans follow. The reports then keep calling it a duplicate of files it no longer matches.

Example from the test:

special/a/-dash.txt and special/b/-dash.txt were recorded as duplicates.
The first was replaced by different content of the same size, with an older mtime. cp -p, rsync -a, tar and a restore from backup all write a file with the mtime it had before.
scan counted the file as unchanged. report and trees still listed the pair, and cmp said the two files differ.

README.md says of files under 100 MiB that a match "proves identical content". Here a complete scan leaves a wrong hash in the database, so that sentence does not hold.

This is as specified: "The mtime matches when it is not newer than the recorded one" has been in the README since you specified the database (your commit e0d578a). So it is a question, not a bug.

Why a user expects it

rsync and make treat any difference in mtime as a change. A user who puts back an older version of a file expects the next scan to notice.

What it would take

One comparison in scan: the mtime differs, in place of the mtime is newer.
The sentence in README.md under "What a scan does to the database", and one test.

The catch: a file whose mtime moves back while its content stays the same is read again once. That happens when a tree is restored onto a filesystem that keeps coarser timestamps.

Your choices

Any change of mtime: build the above.
Newer only: nothing changes. The README then says that a file put back with an older mtime keeps its old record.

Recommended: Any change of mtime.

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 `scan` reads a recorded file again only when its size differs or its mtime is newer than recorded. A file replaced by another of the same size with an older mtime is never read again, however many scans follow. The reports then keep calling it a duplicate of files it no longer matches. Example from the test: - `special/a/-dash.txt` and `special/b/-dash.txt` were recorded as duplicates. - The first was replaced by different content of the same size, with an older mtime. `cp -p`, `rsync -a`, `tar` and a restore from backup all write a file with the mtime it had before. - `scan` counted the file as unchanged. `report` and `trees` still listed the pair, and `cmp` said the two files differ. `README.md` says of files under 100 MiB that a match "proves identical content". Here a complete scan leaves a wrong hash in the database, so that sentence does not hold. This is as specified: "The mtime matches when it is not newer than the recorded one" has been in the README since you specified the database (your commit `e0d578a`). So it is a question, not a bug. ## Why a user expects it `rsync` and `make` treat any difference in mtime as a change. A user who puts back an older version of a file expects the next scan to notice. ## What it would take - One comparison in `scan`: the mtime differs, in place of the mtime is newer. - The sentence in `README.md` under "What a scan does to the database", and one test. The catch: a file whose mtime moves back while its content stays the same is read again once. That happens when a tree is restored onto a filesystem that keeps coarser timestamps. ## Your choices - **Any change of mtime**: build the above. - **Newer only**: nothing changes. The README then says that a file put back with an older mtime keeps its old record. Recommended: **Any change of mtime**. Model: fable-5-2

sneak was assigned by clawbot

2026-11-11 01:06:04 +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:18:48 +01:00

rec approved, should have been built this way in the first place

clawbot commented

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

sneak approved the recommendation above (chat via tracker, 11 November about 02:20 UTC); it is the definition of done, built as one PR into next with tests and README changes.

Model: opus-5-5

sneak approved the recommendation above (chat via tracker, 11 November about 02:20 UTC); it is the definition of done, built as one PR into `next` with tests and README changes. Model: opus-5-5

sneak was unassigned by clawbot

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

clawbot referenced this issue from a commit

2026-11-11 03:29:41 +01:00

Hash a file again when its mtime moved back, not only forward (closes #176)

clawbot referenced a pull request that will close this issue

2026-11-11 03:29:51 +01:00

Hash a file again when its mtime moved back, not only forward (closes #176) #182

clawbot commented

2026-11-11 03:29:55 +01:00

Built in #182: scan hashes a file again when its mtime differs from the record, older or newer. The README says so, and a new test covers an older mtime.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/sfdupes/pulls/182: `scan` hashes a file again when its mtime differs from the record, older or newer. The README says so, and a new test covers an older mtime. Model: opus-5-5

clawbot referenced this issue from a commit

2026-11-11 03:55:57 +01:00

Hash a file again when its mtime moved back, not only forward (closes #176)

clawbot referenced this issue from a commit

2026-11-11 05:22:54 +01:00

Hash a file again when its mtime moved back, not only forward (closes #176) (#182)

clawbot closed this issue

2026-11-11 05:22:54 +01:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/sfdupes#176