sneak/sfdupes
1
0 Fork 0
Code Issues 5 Pull Requests 1 Actions 16 Packages Projects Releases Wiki Activity

proposal: guard the daily scan against a disk that is not mounted #175

New Issue
Closed
opened 2026-11-11 01:06:03 +01:00 by clawbot · 3 comments
clawbot commented 2026-11-11 01:06:03 +01:00
Collaborator
Copy link
Copy source

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

What is missing

Nothing protects the database from a disk that is not mounted. When a filesystem at or below a scanned path is missing, its mount point is an empty directory. scan finds no files there, deletes every record under it and exits 0, so cron sends no mail. The next scan, with the disk back, hashes every file again.

Example from the test, with an empty directory standing in for the mount point:

  • The database held 80000 records under the operand.
  • One scan with the operand empty printed scan: 0 files seen (0 added, 0 updated, 80000 removed, 0 unchanged), 0 skipped and exited 0.
  • The next scan, with the files back, hashed all 80000 again.

On the server sfdupes is meant for, about ten million files and 150 TB, one failed mount before the nightly scan costs the whole first scan again.

The cron line in README.md ("Daily scan from cron") scans /srv with no check.

Why a user expects it

The database is the product of days of reading. A user expects a failed mount to lose one night's scan, not the database.

Your choices

  • Guard in the README's cron line: the line first tests mountpoint -q /srv. When the test fails, it prints one line, which cron mails, and does not start the scan. One sentence says why. No code changes. The user names the mount points that matter.
  • Check in scan: scan deletes nothing and exits 1 when an operand that has records in the database holds no files at all. A tree that really was emptied then needs a way to say so, which is more to build and to explain.
  • Leave as is.

Recommended: Guard in the README's cron line.

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 Nothing protects the database from a disk that is not mounted. When a filesystem at or below a scanned path is missing, its mount point is an empty directory. `scan` finds no files there, deletes every record under it and exits 0, so `cron` sends no mail. The next scan, with the disk back, hashes every file again. Example from the test, with an empty directory standing in for the mount point: - The database held 80000 records under the operand. - One scan with the operand empty printed `scan: 0 files seen (0 added, 0 updated, 80000 removed, 0 unchanged), 0 skipped` and exited 0. - The next scan, with the files back, hashed all 80000 again. On the server `sfdupes` is meant for, about ten million files and 150 TB, one failed mount before the nightly scan costs the whole first scan again. The `cron` line in `README.md` ("Daily scan from `cron`") scans `/srv` with no check. ## Why a user expects it The database is the product of days of reading. A user expects a failed mount to lose one night's scan, not the database. ## Your choices - **Guard in the README's `cron` line**: the line first tests `mountpoint -q /srv`. When the test fails, it prints one line, which `cron` mails, and does not start the scan. One sentence says why. No code changes. The user names the mount points that matter. - **Check in `scan`**: `scan` deletes nothing and exits 1 when an operand that has records in the database holds no files at all. A tree that really was emptied then needs a way to say so, which is more to build and to explain. - **Leave as is**. Recommended: **Guard in the README's `cron` line**. Model: fable-5-2
sneak was assigned by clawbot 2026-11-11 01:06:03 +01:00
sneak commented 2026-11-11 03:19:39 +01:00
Owner
Copy link
Copy source

sure, update the readme. let's not focus too much on the cron use case until post-1.0

sure, update the readme. let's not focus too much on the cron use case until post-1.0
clawbot commented 2026-11-11 03:24:02 +01:00
Author
Collaborator
Copy link
Copy source

sneak (11 November, about 02:19 UTC): approved as a README change only: say plainly what happens when a scanned disk is not mounted. No code for the daily-scan case before 1.0.

Model: opus-5-5

sneak (11 November, about 02:19 UTC): approved as a README change only: say plainly what happens when a scanned disk is not mounted. No code for the daily-scan case before 1.0. Model: opus-5-5
sneak was unassigned by clawbot 2026-11-11 03:24:03 +01:00
clawbot commented 2026-11-11 04:54:35 +01:00
Author
Collaborator
Copy link
Copy source

Built as a README change in #186: the cron section now says what an unmounted disk does to the database, and its line runs scan only when mountpoint -q /srv succeeds.

Model: opus-5-5

Built as a README change in https://git.eeqj.de/sneak/sfdupes/pulls/186: the `cron` section now says what an unmounted disk does to the database, and its line runs `scan` only when `mountpoint -q /srv` succeeds. Model: opus-5-5
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
critical
Extremely important: data loss, a security hole, production down, or basic use impossible
 merge-ready
Review passed; ready to merge
 needs-checks
CI checks failing or not yet green
 needs-decision
needs-decision
Waits on a decision only sneak can make
 needs-decision
Waits on a decision before work continues
 needs-rebase
Branch conflicts with main; rebase required
 needs-review
PR awaiting independent adversarial review
 needs-rework
Review found blocking problems; author must rework
 post-1.0
postponed by sneak until after 1.0
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
clawbot sneak (Jeffrey Paul)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/sfdupes#175