Re-inserting a card that has already been imported produced a folder full of
`-1` copies. Both halves of the placement logic treated a taken name as a
collision to rename around, which is right for the case they were written for
— two cameras both writing IMG_0001.CR3 — and exactly wrong for the far more
common one, where the taken name is the same photograph.
Locally this cannot be answered from the catalog. On a library whose catalog
describes a *server*, a file sitting in the local destination has no row to be
found by, so the only way to know whether it has already been copied is to
look. The destination folder is listed once per folder rather than probed per
file: a card is two thousand frames landing in a handful of days.
Remotely the same question is one PROPFIND that was already being made to
resolve the name, so `upload_original` now returns `Placed::AlreadyThere`
instead of inventing a second copy of work that is already safe. The count is
reported apart from `uploaded`, because "12 already on the server" and "12
uploaded" are different answers to whether this run backed anything up — and
apart from the local duplicate count, because these files *were* copied here.
Name plus length decides it, not a digest: this runs before any transfer, and
hashing to answer it would read the whole card to avoid reading the whole card.
A camera reusing a filename after IMG_9999 writes a different number of bytes
essentially always, which leaves the rename for the case it is really for. The
digest tier still catches the same frame under a different name.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The transport was built and had nowhere to aim: put_chunked has existed since
the connector landed, and the only things pushed through it are thumbnail
shards and the catalog snapshot.
The folder segments arrive already expanded, from dr_ingest::layout, rather
than being re-derived here. That split is what makes FR-NC-7a's first
consequence true — if this module worked out the folders from whatever the
local library happened to look like, two machines with differently organised
libraries would file the same photograph in two different places on one
server.
A name is resolved against one listing rather than a probe per candidate: a
day folder is one PROPFIND and the answer covers every collision in it, where
probing costs a round trip per attempt over a link that may be mobile data.
Two cameras both produce IMG_0001.CR3, and the second must not overwrite the
first.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dtourolleandClaude Opus 5