scan and dwim without root: the error does not say to run as root or set SFDUPES_DATABASE #171

New Issue

2026-11-11T01:03:44+01:00

clawbot commented

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

Defect, found in the acceptance test (#164) on next at 202f083.

Steps

As a user other than root, with SFDUPES_DATABASE unset:

make build
./sfdupes scan "$(mktemp -d /var/tmp/sfdupes.XXXXXX)"

What happened

scan prints this and exits 1, and so does sfdupes dwim:

scan: new database /var/lib/sfdupes/db.sqlite (default)
sfdupes: create database directory: mkdir /var/lib/sfdupes/: permission denied

Nothing says what to do next. README.md says dwim and scan should run as root and that SFDUPES_DATABASE names another database, but the program says neither, and --help does not name the variable.

The matching error of report does give the hint:

sfdupes: /var/lib/sfdupes/db.sqlite: no database (run "sfdupes scan" first, or set SFDUPES_DATABASE)

Why it matters

dwim is the one command for a first look at a new machine. A user who tries it without sudo gets an error with no way forward.

What should happen

When the database, its directory or its lock file cannot be created for lack of permission, the error names both ways out, for example:

sfdupes: create database directory: mkdir /var/lib/sfdupes/: permission denied (run as root, or set SFDUPES_DATABASE)

Model: fable-5-2

Defect, found in the acceptance test (https://git.eeqj.de/sneak/sfdupes/issues/164) on `next` at `202f083`. ## Steps As a user other than root, with `SFDUPES_DATABASE` unset: ```sh make build ./sfdupes scan "$(mktemp -d /var/tmp/sfdupes.XXXXXX)" ``` ## What happened `scan` prints this and exits 1, and so does `sfdupes dwim`: ``` scan: new database /var/lib/sfdupes/db.sqlite (default) sfdupes: create database directory: mkdir /var/lib/sfdupes/: permission denied ``` Nothing says what to do next. `README.md` says `dwim` and `scan` should run as root and that `SFDUPES_DATABASE` names another database, but the program says neither, and `--help` does not name the variable. The matching error of `report` does give the hint: ``` sfdupes: /var/lib/sfdupes/db.sqlite: no database (run "sfdupes scan" first, or set SFDUPES_DATABASE) ``` ## Why it matters `dwim` is the one command for a first look at a new machine. A user who tries it without `sudo` gets an error with no way forward. ## What should happen When the database, its directory or its lock file cannot be created for lack of permission, the error names both ways out, for example: ``` sfdupes: create database directory: mkdir /var/lib/sfdupes/: permission denied (run as root, or set SFDUPES_DATABASE) ``` Model: fable-5-2

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:24:31 +01:00

if run by nonroot make the database file go somewhere sane (xdg state directory)

clawbot commented

2026-11-11 03:39:34 +01:00

sneak (11 November, about 02:24 UTC), the definition of done: run without root, scan and dwim put the database in the XDG state directory ($XDG_STATE_HOME/sfdupes/, defaulting to ~/.local/state/sfdupes/), creating it as needed, instead of failing; as root the current location stays. SFDUPES_DATABASE still overrides both. README and --help say where the database lives. Tests cover the non-root default and the override.

Model: opus-5-5

sneak (11 November, about 02:24 UTC), the definition of done: run without root, `scan` and `dwim` put the database in the XDG state directory (`$XDG_STATE_HOME/sfdupes/`, defaulting to `~/.local/state/sfdupes/`), creating it as needed, instead of failing; as root the current location stays. `SFDUPES_DATABASE` still overrides both. README and `--help` say where the database lives. Tests cover the non-root default and the override. Model: opus-5-5

clawbot referenced this issue from a commit

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

Keep a non-root user's database in the XDG state directory (closes #171)

clawbot referenced a pull request that will close this issue

2026-11-11 05:00:38 +01:00

Keep a non-root user's database in the XDG state directory (closes #171) #190

clawbot commented

2026-11-11 05:00:47 +01:00

Built in #190: without SFDUPES_DATABASE, a non-root user's database is sfdupes/db.sqlite under $XDG_STATE_HOME (~/.local/state by default), created by scan; root keeps /var/lib/sfdupes/db.sqlite. report, trees and info follow the same default, so a non-root user reads root's database only with SFDUPES_DATABASE set.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/sfdupes/pulls/190: without `SFDUPES_DATABASE`, a non-root user's database is `sfdupes/db.sqlite` under `$XDG_STATE_HOME` (`~/.local/state` by default), created by `scan`; root keeps `/var/lib/sfdupes/db.sqlite`. `report`, `trees` and `info` follow the same default, so a non-root user reads root's database only with `SFDUPES_DATABASE` set. Model: opus-5-5

clawbot referenced this issue from a commit

2026-11-11 07:06:37 +01:00

Keep a non-root user's database in the XDG state directory (closes #171)

clawbot referenced this issue from a commit

2026-11-11 09:01:31 +01:00

Keep a non-root user's database in the XDG state directory (closes #171)

clawbot referenced this issue from a commit

2026-11-11 09:40:23 +01:00

Keep a non-root user's database in the XDG state directory (closes #171)

clawbot closed this issue

2026-11-11 10:07:13 +01:00

clawbot referenced this issue from a commit