Say which database file each command uses, and document when scan writes to it #111

Closed
opened 2026-10-16 13:50:33 +02:00 by clawbot · 1 comment
Collaborator

sneak, on #56 (comment):

> Took far too long, strace on the pid was hanging too. No idea why it was hanging, I don't even know where the database file is/was. Please diagnose.

and on #56 (comment):

> meanwhile, nothing is created in /srv/tmp/sfdupes.

The binary he ran was v0.0.1, which has no database (#56 (comment)). The release candidate has a gap of its own here: scan, report and trees never say which database file they are using, so a user who set SFDUPES_DATABASE in another shell, or forgot it, finds out the path only from an error. The README says scan creates the database "on first use", but not when records first reach it.

Definition of done

  • scan, report and trees each print one line on stderr naming the database in use, before anything else they print (progress displays included), on a terminal and off one. It gives the path as an absolute path (a relative SFDUPES_DATABASE resolved against the working directory) and says where it came from, for example scan: database /var/lib/sfdupes/db.sqlite (default) or trees: database /srv/tmp/sfdupes/db.db (from SFDUPES_DATABASE). The exact wording is the implementer's. For scan the line also says when the file is new (created by this scan).
  • For report and trees the line comes before the database is opened, so a missing-database error follows it.
  • README "Database" says plainly when each file is written: as scan starts, the directory, an empty database file and the .lock file; then the schema and, while it runs, the -wal and -shm files, before the walk; no records while it loads and walks; the first records during the hash phase, committed 10,000 at a time; records for size-unique files and deletions in the update phase; content hashes in the content phase; at the end the -wal and -shm files go away. It also shows the new line. "Daily scan from cron" mentions it.
  • Tests: each command's first stderr line, for the default path and for a relative SFDUPES_DATABASE; scan saying the database is new on the first run and not on the second.
  • TODO.md Completed Steps entry in the same commit; script/cibuild green on a fresh clone.

Notes for the implementer

  • Package main (the repo's only package). The path and where it came from belong with databasePath in db.go, whose doc covers locating the database; the three commands print the line at their start (scan.go, report.go, trees.go).
  • Small and plain: one helper that returns the absolute path and its source, one print per command. No new flags.

Model: opus-5-5

sneak, on https://git.eeqj.de/sneak/sfdupes/issues/56#issuecomment-145001: > Took far too long, strace on the pid was hanging too. No idea why it was hanging, I don't even know where the database file is/was. Please diagnose. and on https://git.eeqj.de/sneak/sfdupes/issues/56#issuecomment-145002: > meanwhile, nothing is created in `/srv/tmp/sfdupes`. The binary he ran was `v0.0.1`, which has no database (https://git.eeqj.de/sneak/sfdupes/issues/56#issuecomment-145003). The release candidate has a gap of its own here: `scan`, `report` and `trees` never say which database file they are using, so a user who set `SFDUPES_DATABASE` in another shell, or forgot it, finds out the path only from an error. The README says `scan` creates the database "on first use", but not when records first reach it. ## Definition of done - `scan`, `report` and `trees` each print one line on stderr naming the database in use, before anything else they print (progress displays included), on a terminal and off one. It gives the path as an absolute path (a relative `SFDUPES_DATABASE` resolved against the working directory) and says where it came from, for example `scan: database /var/lib/sfdupes/db.sqlite (default)` or `trees: database /srv/tmp/sfdupes/db.db (from SFDUPES_DATABASE)`. The exact wording is the implementer's. For `scan` the line also says when the file is new (created by this scan). - For `report` and `trees` the line comes before the database is opened, so a missing-database error follows it. - README "Database" says plainly when each file is written: as `scan` starts, the directory, an empty database file and the `.lock` file; then the schema and, while it runs, the `-wal` and `-shm` files, before the walk; no records while it loads and walks; the first records during the hash phase, committed 10,000 at a time; records for size-unique files and deletions in the update phase; content hashes in the content phase; at the end the `-wal` and `-shm` files go away. It also shows the new line. "Daily scan from cron" mentions it. - Tests: each command's first stderr line, for the default path and for a relative `SFDUPES_DATABASE`; `scan` saying the database is new on the first run and not on the second. - `TODO.md` Completed Steps entry in the same commit; `script/cibuild` green on a fresh clone. ## Notes for the implementer - Package `main` (the repo's only package). The path and where it came from belong with `databasePath` in `db.go`, whose doc covers locating the database; the three commands print the line at their start (`scan.go`, `report.go`, `trees.go`). - Small and plain: one helper that returns the absolute path and its source, one print per command. No new flags. Model: opus-5-5
clawbot added this to the 1.0.0 milestone 2026-10-16 13:50:33 +02:00
Author
Collaborator

Built in #118: scan, report and trees now print a first line on stderr such as scan: new database /var/lib/sfdupes/db.sqlite (default), and README "Database" lists when scan writes each file. The PR body has the details and disclosures.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/sfdupes/pulls/118: `scan`, `report` and `trees` now print a first line on stderr such as `scan: new database /var/lib/sfdupes/db.sqlite (default)`, and README "Database" lists when `scan` writes each file. The PR body has the details and disclosures. Model: opus-5-5
Sign in to join this conversation.