Final review of #313:
- C1: the duplicate find tells files apart by (st_dev, st_ino), so a
source listed twice, a symlinked source inside another and a hardlink
are one file. The preview and the job refuse a removal that
os.path.samestat matches with its kept copy.
- I1: each file's records move to its verified kept copy in one short
transaction before that file is unlinked; a failed move deletes
nothing and a failed unlink leaves the records on the identical kept
copy. The status line counts files removed and not removed.
- I2: links are looked up under every spelling of the source (the real
path, the configured and monitored folders, ComfyUI's output).
- I5: image tags join the kept copy as their union and the removed
copy's pending, undecided Needs review items are settled; the plan
says so.
- I3: the VACUUM disk check measures SQLite's real temporary folder.
- M1: the token is looked at again with no await before the job starts.
- M2: the backup decision is made once and handed to the job.
- M3: backups are linked into place; startup sweeps interrupted temps.
- M4: Optimize runs alone (new "exclusive" admission) and its plan says
the database is locked while VACUUM runs.
- M5: the reviewed duplicate merge is strict: collisions and Library
titles are protected, and errors roll back. The legacy cleanup is
unchanged.
- M7: 2,000 keep entries within a 1 MiB body. M8: event waits in tests.
- M9: the preview binds files by size, mtime and inode without hashing;
the job hashes right before each unlink.
Duplicate image files move onto the job registry:
- POST /prompt_manager/jobs/duplicates finds content-identical media
files over every effective source as a cancellable read job
("Find duplicate image files", group groups_found); the server holds
the groups per job and GET /prompt_manager/maintenance/duplicates/{id}
pages them ten at a time.
- The duplicate_files preview binds a removal to the reviewed keepers.
Every keeper and removal is checked again: containment as text before
any filesystem access, then not a link, still inside its source, same
size and hash. The plan lists the database links that move.
- Apply runs duplicate_cleanup (records, not cancellable): the promised
safety backup, then per file a recheck, the unlink with every handle
closed and its thumbnail. A changed file is kept, the first failed
unlink stops the job with a coded message (never the OS text), and only
removed files have their image links and favorites moved to the kept
copy.
- The legacy scan, stream, status and delete routes keep their shapes on
the same registry kinds; the hashing, grouping and thumbnail removal
are shared with them.
Coordinator rulings on Tasks 15-16:
- Safety backups share the restore pool of 10 `<db>.backup_*` files; the
pool is now also pruned when an apply fails after its backup.
- Plans report the safety backup's size and the free disk space, and
apply refuses up front (507 insufficient-space) when the backup or
VACUUM does not fit, so no job fails halfway for space.
Vito Sansevero