Skip to content

Stop deleting a group's copies once the kept copy changes mid-run [patch] - #203

Merged
matt-edmondson merged 2 commits into
mainfrom
fix/201-recheck-keeper-during-delete
Nov 4, 2026
Merged

matt-edmondson merged 2 commits into
mainfrom
fix/201-recheck-keeper-during-delete

Conversation

@matt-edmondson

Copy link
Copy Markdown
Contributor

DeleteDuplicates re-hashed the kept copy once per group, before the delete loop. If a sync client or editor rewrote it after the first deletion, the remaining copies were still deleted and the original content was lost.

Changes

  • After the pre-loop re-hash, record the kept copy's size, last write time and file identity (KeeperSnapshot), and compare them before each deletion. Once they differ, keep every copy still to go and report each as skipped, with a reason that names the kept copy.
  • After a group's last deletion, re-hash the kept copy once more. A rewrite the quick check misses (same size, timestamp put back) is reported as an error, so the run reports errors instead of exiting clean.
  • DeleteDuplicates takes an optional afterDelete callback. Production code passes nothing.
  • README: one paragraph on the new guard.

Tests

  • AKeeperChangedDuringTheDeleteLoopPreservesTheRemainingCopies: rewrites the kept copy after the first of three deletions, then asserts the other two survive and are skipped with the kept copy named.
  • AKeeperRewrittenWithoutChangingSizeOrTimeIsReportedAfterTheGroup: asserts the final re-hash reports the change.
  • Both tests fail with the new checks disabled and pass with them on. Full suite: 123 total, 0 failed (3 skipped, as on main).

Fixes #201


Generated by Claude Code

…tch]

DeleteDuplicates re-hashed the kept copy once per group, before the delete
loop. The loop re-hashes and deletes each other copy, which takes seconds
apiece for large files, and nothing looked at the kept copy again. A sync
client or editor rewriting it after the first deletion left the remaining
copies to be deleted anyway, and the original content existed nowhere.

The kept copy's size, last write time and file identity are now recorded
after the pre-loop re-hash and compared before each deletion. Once they
differ, every copy still to go is kept and reported as skipped with a reason
naming the kept copy. After a group's last deletion the kept copy is
re-hashed once more, and a rewrite the quick check could not see (same size,
timestamp put back) is reported as an error.

DeleteDuplicates takes an optional afterDelete callback, which the tests use
to rewrite the kept copy between two deletions.

Fixes #201

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vfJW5MMN2e4Pk8UWLnvp9
Comment thread FileDeduplicator/Deduplicator.cs Fixed
Comment thread FileDeduplicator/Deduplicator.cs Fixed
@sonarqubecloud

sonarqubecloud Bot commented Nov 3, 2026

Copy link
Copy Markdown

@matt-edmondson
matt-edmondson merged commit ee80798 into main Nov 4, 2026
15 checks passed
@matt-edmondson
matt-edmondson deleted the fix/201-recheck-keeper-during-delete branch November 4, 2026 01:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

If the kept copy is modified while the other copies are being deleted, every remaining copy is still deleted and the original content is lost

2 participants