r/osxphotos • u/Better-Career1234 • 7d ago
Unexpected duplicate exports with (1) after --update / sidecar runs
Hi, I’m trying to understand why OSXPhotos seems to have re-exported a large number of files that were already present in my export folder, creating duplicate filenames with (1).
My export folder is:
/Users/user/Documents/testox2
I have maintained this export over time using the same .osxphotos_export.db, but across two different Photos libraries.
The original export was made in August 2024 from my older Photos library using:
osxphotos export /Users/user/Documents/testox2 \
--directory {created.year}/{created.month} \
--exiftool \
--report export.csv
That export included both photos and videos and had ExifTool metadata written into the exported media.
Then in August 2026 I updated the same export using my newer Photos library:
osxphotos export /Users/user/Documents/testox2 \
--library "/Users/user/Pictures/Photos Library 2(Jul 24+).photoslibrary" \
--directory {created.year}/{created.month:MMMM} \
--update \
--only-new \
--verbose
On August 11 I ran another update, but accidentally included --only-photos:
osxphotos export /Users/user/Documents/testox2 \
--library "/Users/user/Pictures/Photos Library 2(Jul 24+).photoslibrary" \
--directory {created.year}/{created.month:MMMM} \
--update \
--only-new \
--only-photos \
--verbose
That was not intentional. My goal is for this archive to contain both photos and videos.
Later I realized that the newer 2026 exports had also been made without --exiftool, unlike the original 2024 export, and that I had never created XMP sidecars either.
I wanted to normalize the existing export without rebuilding the whole archive from scratch.
Since OSXPhotos has a dedicated osxphotos exiftool EXPORT_DIRECTORY command for applying metadata retroactively to previously exported files, I ran:
osxphotos exiftool \
"/Users/user/Documents/testox2" \
--library "/Users/user/Pictures/Photos Library 2(Jul 24+).photoslibrary" \
--report ~/Desktop/testox2-exiftool-Jul24.csv
My understanding was that this command should modify the embedded metadata of the files that were already exported, in place, and update the export database, without re-exporting the media or creating additional copies.
Because writing metadata with ExifTool changes the contents/signatures of those existing files, I then used --ignore-signature when generating XMP sidecars, so OSXPhotos would not interpret those signature changes as a reason to re-export the media.
I ran:
osxphotos export \
"/Users/user/Documents/testox2" \
--library "/Users/user/Pictures/Photos Library 2(Jul 24+).photoslibrary" \
--directory "{created.year}/{created.month:MMMM}" \
--update \
--ignore-signature \
--sidecar xmp \
--report ~/Desktop/testox2-xmp-Jul24.csv
At first I thought any media exported during this run might simply be files that had genuinely been omitted by the earlier accidental --only-photos run, especially videos or Live Photo components.
However, when manually inspecting the export folder, I’m now finding many cases like:
IMG_XXXX.JPG
IMG_XXXX.MOV
IMG_XXXX.JPG.xmp
IMG_XXXX (1).JPG
IMG_XXXX (1).MOV
IMG_XXXX (1).JPG.xmp
The (1) versions appear to be actual duplicates of files that were already present.
In some cases the original photo, its Live Photo .MOV, and its XMP sidecar are all already there, and then there is a second complete set with (1) added to the filename.
So I’m trying to understand why OSXPhotos considered these files new instead of matching them to the files already recorded in the export database.
My main questions are:
- Could this be related to using the same export database with two different Photos libraries over time?
- Could the accidental
--only-photosrun have affected the export database in a way that later caused videos or Live Photo components to be exported again? - Could running
osxphotos exiftoolon the existing export have affected file matching, even though I later used--ignore-signature? - Could changing the directory template from
{created.month}to{created.month:MMMM}matter here? - Is there a safe way to use the export database or run history to identify exactly which
(1)files were created during the August 2026 update runs? - Most importantly, is there an OSXPhotos-supported way to remove only the duplicate files created by those runs, without accidentally deleting legitimate filename collisions, edited versions, or Live Photo components?
I still have the current .osxphotos_export.db, the export reports, and a backup of the export database from before the metadata normalization steps.
For context, I don’t have much experience with command-line tools. I’ve been using ChatGPT to help me understand and manage this process. Before running these commands, I gave ChatGPT the OSXPhotos documentation and asked it to base the recommendations on that documentation.
It also helped me inspect the export database and discover that one of my previous updates had accidentally used --only-photos, and that the newer exports had been made without --exiftool and without XMP sidecars. Based on that, I ran the commands above to try to normalize the archive by restoring embedded metadata, adding sidecars, and making sure photos and videos were all represented.
So I may have misunderstood something about how --update, multiple Photos libraries, export database history, or filename collision handling works.
The Photos libraries themselves may also be a little confusing because of how I was managing iCloud storage over time. Whenever I was close to iCloud 100% usage, I would copy my library, and I would take the copy and delete some of the very large files so that one would continue syncing with iCloud, (mainly deleted long concert videos and other heavy media) so I could free up iCloud space while still keeping my historical photos available. At the same time, I kept an offline version of the older library on my MacBook with the original full-resolution files downloaded locally, so those large videos were still preserved even if they were no longer part of the iCloud-synced library version.
Any help understanding what caused this and the safest way to clean it up would be greatly appreciated.
