> 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
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
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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,reportandtreesnever say which database file they are using, so a user who setSFDUPES_DATABASEin another shell, or forgot it, finds out the path only from an error. The README saysscancreates the database "on first use", but not when records first reach it.Definition of done
scan,reportandtreeseach 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 relativeSFDUPES_DATABASEresolved against the working directory) and says where it came from, for examplescan: database /var/lib/sfdupes/db.sqlite (default)ortrees: database /srv/tmp/sfdupes/db.db (from SFDUPES_DATABASE). The exact wording is the implementer's. Forscanthe line also says when the file is new (created by this scan).reportandtreesthe line comes before the database is opened, so a missing-database error follows it.scanstarts, the directory, an empty database file and the.lockfile; then the schema and, while it runs, the-waland-shmfiles, 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-waland-shmfiles go away. It also shows the new line. "Daily scan from cron" mentions it.SFDUPES_DATABASE;scansaying the database is new on the first run and not on the second.TODO.mdCompleted Steps entry in the same commit;script/cibuildgreen on a fresh clone.Notes for the implementer
main(the repo's only package). The path and where it came from belong withdatabasePathindb.go, whose doc covers locating the database; the three commands print the line at their start (scan.go,report.go,trees.go).Model: opus-5-5
Built in #118:
scan,reportandtreesnow print a first line on stderr such asscan: new database /var/lib/sfdupes/db.sqlite (default), and README "Database" lists whenscanwrites each file. The PR body has the details and disclosures.Model: opus-5-5