The '--update' flag not skipping already-exported files on macOS Tahoe (26.x)

[sgclark]

I'm running osxphotos 0.75.9 on macOS Tahoe 26.5 (arm64) with Python 3.12 installed via uv. Every time I run the export command, all photos are re-exported with skipped: 0, even immediately after a previous successful run with the same command against the same destination folder.

My command:
osxphotos export /Users/stephengclark/Pictures/master_photo_files --directory "{folder_album}" --update --exiftool --from-date 2026-01-01 --not-shared --in-album --skip-edited

Every run produces:
Processed: 825 photos, exported: 830, updated: 0, skipped: 0

The .osxphotos_export.db database exists in the destination folder and is being found. I also tried --ignore-signature with no improvement. Is this a known Tahoe compatibility issue?

Thanks
Stephen

[RhetTbull]

This shouldn't happen. I've not tested on 26.5 but on 26.4 --update works as expected. Try adding the following to your command and run again:

--watch osxphotos.photoexporter::PhotoExporter._should_update_photo

This will print debug output that will include a line like this:

2026-05-27T22:21:51.784780 _should_update_photo returned: ShouldUpdate.EXIFTOOL_DIFFERENT, elapsed time: 9.983400013879873e-05 sec

which should help figure out why osxphotos is exporting the photos again. In the example abnove, ShouldUpdate.EXIFTOOL_DIFFERENT indicates the exiftool metadata was different and needed to be rewritten.

The following command might also have some clues as it shows the history for a given file:

osxphotos exportdb /Users/stephengclark/Pictures/master_photo_files --history /path/to/an/exported/photo

[sgclark]

Thanks for responding. This detail was helpful.

From a Feature perspective, is it possible to consider adding UUID as a method to track the images? Currently --update tracks files by filename + size + modification time as you noted in specs. If files are renamed by an external tool (e.g. Hazel) after export, osxphotos can't find them and re-exports them as duplicates. Since Photos assigns a permanent UUID to every photo, using that as the tracking key would make --update resilient to any external renaming.

[sgclark]

Additionally, I notice --uuid and --skip-uuid-from-file already exist as export options. Is there a way to use these in combination with the export database to skip photos whose UUID already exists in an exported file on disk? Specifically, could --update be enhanced to check the UUID stored in EXIF (written by --exiftool) rather than relying on filename matching?

[RhetTbull]

UUID is unique but not permanent. The same photo on two different Macs will have different UUIDs. Rebuilding the library can also change UUID. I recommend against writing UUID to the EXIF for this reason.

You could write a script to dump UUIDs from the export database and use that as input to --uuid-from-file

Why are you renaming photos with Hazel? Could you use OSXPhotos template system to create the photos using the desired naming scheme?

[sgclark]

I've only recently discovered osxphotos and all of its capabilities. Apologies for being late to the party. LOL :). For the longest time, I've downloaded pix from Apple Photos/iPhone via Dropbox (via their "Camera Upload" feature) which would then load them to Dropbox directory in Finder. Then via a Hazel script, I'd move them into my 'pictures' archive/directory where Hazel would then rename them to reflect date/time/device/os. Seeing that I can do that via osxphotos and also feed the pix and the Apple Photos folders to sync directly from Apple Photos to my 'pictures' archive is a game changer.