Jamie PineandClaude Opus 5 c78cf8f319 Delete what the entries world was still holding up ...

Four things with no callers, found by asking rather than assuming.
file_sync built a conduit between two locations and copied files along it;
`file_sync_service()` is constructed lazily and nothing ever asks for it.
locations.export and import dumped the entry tables to SQL and read them
back, unreachable from client or CLI, and a source store is already a single
SQLite file someone can copy. search/filters.rs built sea-orm conditions over
entry columns for the FTS search that went in 7d41e07ab; it looked live
because ops::search re-exports it. hierarchy.rs answered descendant queries
from the closure table, and its last caller left with the persistent indexer.

Library statistics were the real find. They summed entry.size over the
closure table, so with nothing writing entries they had quietly become zero,
and there were two copies of every calculation, static and instance, that had
to agree. Now each source reports its own totals and the two versions are one.

That needed the store to count more than it did. counts() answered records
and bytes; it answers directories and contents too, in the same query. Files
are records less directories, because a folder is a record and nobody asking
how many files they have means folders. content_count is a new column on
sources, since record_count counts rows and unique_bytes counts bytes and
neither says how many separate files a drive holds once copies fold together.

Unique content is per-source and will over-count across drives until the
catalog exists: two drives holding the same photo report one each. That is
visible on the overview, and it is the same gap files.duplicates documented.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-09 22:48:51 -07:00

..

src

Delete what the entries world was still holding up

2026-09-09 22:48:51 -07:00

Cargo.toml

…