Since a content duplicate carries its file's capture time, the duplicate
check ran after the sidecar read, so a duplicate whose file already has
a capture time read and parsed a sidecar it doesn't use (more I/O on a
network share). The check now happens first and the sidecar is read for
a duplicate only when the file has no capture time.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A content duplicate whose catalog row has no capture time took the
capture time of the library photo with the same bytes, which Edit
Capture Time may have changed. The import job now resolves the file's
capture time (the file's, else its XMP sidecar's, else its modification
time) before it sets the file aside as a duplicate, and hands it over
with the file's metadata (`Duplicate::file`, a `FileFacts`). The
Lightroom import uses it; the catalog's capture time still applies on
top when the row has one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose bytes match another library photo became a new record that took only the
camera description from that photo's record, so the copyright, rights, creator and other metadata
its file carries (EXIF, IPTC, embedded XMP), which a file import keeps, was lost whenever the
catalog's XMP didn't restate it. Copying them from the other record would have carried that
photo's edits instead.
The file import already reads each content duplicate before it skips it; the probed metadata now
rides on the duplicate (`Duplicate::file_meta`, not serialised) and the new record starts from it,
before the import defaults and the catalog's metadata go on top, as for a file import. Without a
probe (a path match, which this branch never sees) it keeps the exposure description only, no
longer the user-editable GPS.
Test: a content duplicate of a trashed photo, imported through the Lightroom job with a file
carrying copyright, status, usage terms and creator, keeps them and takes nothing from the other
record's edited notice, creator or GPS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose bytes match another library photo got the generic develop defaults, so a raw
with no white balance or lens setting in the catalog lost its as-shot white balance and embedded
lens corrections and rendered unlike a file import. It now gets the import defaults (camera
defaults plus the default preset), as a file import does, before the catalog's settings go on top.
Show in Library selected the lowest mapped photo id, which can be a master left in Recently Deleted
whose new virtual copy the import added; All Photos doesn't show it. It now selects the lowest
mapped photo not in Recently Deleted, and the button is left out when there is none.
Tests: a content-duplicate raw with no catalog settings equals its camera defaults (as-shot WB,
lens profile on); Show in Library skips a trashed mapped photo and offers nothing when only
trashed or vanished ids are mapped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The new record for a catalog photo whose bytes match another library photo copied that whole
record and reset a few fields, so the other photo's edits, history, versions, ratings and written
metadata (title, keywords, face regions) carried over, from a trashed photo too. It now starts as a
new photo and takes only what the bytes determine: format, size, kind, capture time, camera EXIF,
GPS, focus point, content hash, embedded lens data and preview-only state. The catalog's own
settings and metadata apply on top as before.
Tests: the duplicate test gives the other photo edits, history, a version, a title, keywords and a
Local baseline and checks none reach the new record; a reimport after a master and its virtual copy
were trashed counts each once.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A catalog photo whose file matched a photo in Recently Deleted by content was cloned with the trashed
record's `deleted` flag (and its virtual-copy fields), so it landed in Recently Deleted while the report
counted it as imported. A new virtual copy of a trashed master did the same. Both are now live records,
as Create Virtual Copy already does.
Catalog photos matched by path to a trashed photo stay there (the Lightroom import's OnDeleted::Skip,
#706); the report counts them as `inRecentlyDeleted` and the result window says so in one line.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
AGENTS.md (and CLAUDE.md where present) gets a CI workflows section: workflows only call
craft-common-actions at @main, with no other jobs; feature and fix PRs don't touch CI and
link or open a craft-common-actions issue (a PR only for a small fix that is safe for
every app and does not increase CI time); legacy jobs
aren't added to and move only as their own task, staying until a shared workflow runs them.
windows-arm64.yml moves from its SHA pin to @main. The pinned revision is on
craft-common-actions main and the workflow (and the actions it calls) is identical
there, so nothing changes in behaviour.
* Honor CARGO_BUILD_TARGET in FreeBSD packaging for aarch64 release builds
package.sh always built for the host and took the arch from uname -m, so a
cross build (aarch64 in an x86_64 FreeBSD VM) would read the wrong target
directory and name the archive after the VM. With CARGO_BUILD_TARGET set,
pass it to cargo, read target/<triple>/release, and take the arch from the
target. Unset keeps the old behavior.
* Reject unknown CARGO_BUILD_TARGET in FreeBSD packaging
Only the two FreeBSD triples are packaged. Any other target now fails before the
build instead of being labelled x86_64.
* Skip the --version smoke run for cross-built FreeBSD packages
A binary built for another target cannot run on the build host, so under set -e
the run would fail the release after the archive is written.
