why is adobe folder synchronization still broken?

Report · May 27, 2019

why is adobe LR 8.3 changing images when you synchronize a folder?

why is it touching images that are not edited/changed in any way?

i actually searched the forum and i read this a few times .... and it´s a PITA.

i just synchronized a folder and LR was touching EVERY images in the folder and subfolders and changed it´s timestamp.

the images are not changed in any way by me. so in my opinion LR has to do NOTHING to these images. yet they are all set to 27.05.2019.

that means that my automatic backup will copy them over to all my backup drives.

can someone explain this to me?

these are the changes LR has made to the images:

all i have done is synchronizing a folder i have not touched in month.

i read that some people had thousands of images that are altered.
that means that hundreds of gigabytes will be be copied to backup drives because the synchronize feature is basically broken.

Report · May 27, 2019

When you check the metadata of any of these images are there changes there?

Report · May 27, 2019

i have posted above what has changed.

what you see is the result of a binary compare. no keywords are changed, no edits were made.

i have not changed the process version either. the process version of the changed images is still V4 and not v5.

and its the same for all images. here is another example:

on the left the changed image. on the right an backup of that image (state before i synchronized the folder).

i mean this seems not to be news. when you search the forum you will see this was noticed years ago.

i think it is even mentioned on the LR feedback forum.

Report · May 27, 2019

Lightboxx wrote
i mean this seems not to be news. when you search the forum you will see this was noticed years ago.
i think it is even mentioned on the LR feedback forum.

I can't duplicate what you're seeing and neither can I find these posts you mention. It would help to show us those reports. Keep in mind if you have 'Automatically write changes into XMP' checked in the Catalog Settings ANY change made inside LR (keyword or other metadata, Develop settings, Rating, etc.) will cause the file to be updated and time stamp changed.

My first suggestion is to reset your LR Preferences file as detailed at the below link. It can become corrupted and cause unexplained issues. You can move the Preferences file to your desktop, which allows restoring it if the issue persists. LR will create a new Preferences file with the default settings. Try the same geotagging workflow on a few new files and see if the issue is fixed. If you had 'Automatically write changes into XMP' checked in the Catalog Settings you need to check it before running this test. However, do not change any other settings so we have a baseline for troubleshooting.

Report · May 27, 2019

Keep in mind if you have 'Automatically write changes into XMP' checked in the Catalog Settings ANY change made inside LR (keyword or other metadata, Develop settings, Rating, etc.) will cause the file to be updated and time stamp changed.

as i wrote above: i made no changes.

you can also see that in the binary compare screenshots i posted two times now.

if there would be changes to the files (keywords, setting, ratings etc.) they would be shown in the binary compare of the file.

but there are none....

i don´t know what more proof you need that there is no change made by me?

when adobe thinks that synchronizing a folder is making changes to a file that is not changed..... well stupid i would say.

My first suggestion is to reset your LR Preferences file as detailed at the below link. It can become corrupted and cause unexplained issues. You can move the Preferences file to your desktop, which allows restoring it if the issue persists. LR will create a new Preferences file with the default settings

has nothing to do with my settings. it was mentioned before by other users. this is a faulty behavior of LR.

as reported by other users before.

neither can I find these posts you mention.

do a search for " why is lightroom changing DNG files"

that is one i remember. there are more but i can´t be bothered to search them.

i spend to much time on this already.

Report · May 27, 2019

Lightboxx wrote
has nothing to do with my settings.

I said it's possible you have a corrupted Preferences file, which can cause LR do do strange things. It's a simple test! As a part of that test it's important to know which settings actually cause the issue. This is trouble shooting 101, which you will need to do to convince Adobe there is a problem. Then you can report this as a 'Problem' at the below link, which is monitored by Adobe staff.

Post a Conversation | Photoshop Family Customer Community

Lightboxx wrote
it was mentioned before by other users. this is a faulty behavior of LR.
as reported by other users before.

Where are the links to those reports. You should include them here and in your report to Adobe at the Photoshop Family forum link above. Thank you.

Report · May 27, 2019

Where are the links to those reports. You should include them here and in your report to Adobe at the Photoshop Family forum link above. Thank you.

see above.

you even took part in that thread.

and you really need to read such threads carefully.

when i read that thread i always thought "that guy (you) is desperately searching for an excuse that has nothing to do with LR."

and after some discussion you wrote "I have no idea what is causing the displayed binary differences, but you say the file contains no changes to Develop settings or other metadata correct? If so then it is a pretty clear indication of a LR bug."

Report · May 27, 2019

Lightboxx wrote

do a search for " why is lightroom changing DNG files"
that is one i remember. there are more but i can´t be bothered to search them.
i spend to much time on this already.

Here's the only post that comes up with the search string "why is lightroom changing DNG files."

Why is LIGHTROOM changing DNG files on it´s own?

I suggest you read the post in its entirety and then if still convinced it's a LR Classic issue report it with full details on the exact workflow steps needed to duplicate it at the link I provided. You also need to provide the name of the geotagging app and how you use it. If you can duplicate the issue with a workflow that uses only Adobe apps (LR, PS Bridge) so much the better!

Lacking these "details" I can guarantee you Adobe will not be able to "fix" this issue.

Report · May 27, 2019

I can confirm the OP's behaviour - Win10, LR 8.3 (201905061635)

Raws (PEF) and XMPs in a folder.

Sync this Folder, selecting "scan metadata for changes". This scan is detected as an update action to the Catalog metadata of each image, even if no changes are found. Then if enabled, LR Auto-writes an update to the XMP file changing its modification date/time.
Sync this Folder, deselecting "scan" option. No updates to existing metadata timestamp in the Catalog, no re-writing of XMP externally.

The OP's use case requires bringing in externally changed metadata, but IMO Sync Folder is a sledgehammer for that particular nut.

Image files where the external metadata HAS been changed by another program, should have their modification date updated regardless. So the only remaining bit of the puzzle, is getting those geo-encoding changes, and those only, into the Catalog.

Fortunately LR notices when external metadata is changed subsequent to its own last writing-out. So LR displays a warning icon.

so, Workaround Suggestion: make a Smart Collection with criteria as follows (ALL must be true):

[Metadata Status] "is" "changed on disk"

[Edit date] "is in the last" (say) 7 days.

This SC will show all images with XMP that has been changed externally - not by LR - during the last week. Highlight all these.

Alt+M, R to Read metadata from disk. This selectively updates only these images within the Catalog.

Report · May 27, 2019

Nice way to make Smart Collections work for you in this scenario.

Report · May 27, 2019

richardplondon schrieb
I can confirm the OP's behaviour - Win10, LR 8.3 (201905061635)
The OP's use case requires bringing in externally changed metadata, but IMO Sync Folder is a sledgehammer for that particular nut.
Image files where the external metadata HAS been changed by another program, should have their modification date updated regardless. So the only remaining bit of the puzzle, is getting those geo-encoding changes, and those only, into the Catalog.

thanks that you tested it.

the smartcollection may help in the case of my geotagged files.

at least when they are already in the catalog, unfortunately they are not always.

sometimes i also re-edit images with photoshop and save a copy of these file.

i save them from photoshop and they are not in the LR catalog.

i know the user could do an import.

but LR has this synchronize feature so why not using it?

in the end it is just a fast rightclick on a folder and chose synchronize.

faster then importing images through the import dialog.

again to make this clear.... the issue has nothing to do with the geotagging app. that is just why i like this workflow.

the changing of files happens no matter what. it only depends on synchronizing a folder.

to be honest i think adobe should change this behavior.

there are sure some workflows where someone likes to synchronize a folder to get new files into LR.

i sure like to do that.

in my opinion no software should touch (write metadata) to a file when no change to that file is made.

that can only introduce issues.

Report · May 27, 2019

In my testing, by unchecking "scan metadata" unchanged images were left alone. So you could use Sync Folder to bring in all the non-imported images (but if you originally sent these photos to PS from LR, they should be already imported).

I do agree that this metadata scan ought not to be updating timestamps needlessly. Your next step may be a Feature Request.

Report · May 27, 2019

richardplondon schrieb
(but if you originally sent these photos to PS from LR, they should be already imported).

but not when i open these images in PS and save a copy.

and while this would sure work. these are extra steps to think about and to keep in mind.

"use the smartcollection to update the files with metadata changes"

"use the synchronize feature, but make sure you uncheck scan metadata, when you want to get new files into the catalog".

if LR would let files alone that are not changed, this would not be an issue.

this is maybe not a big issue for people who only work in LR.

but when you work with other software then it´s quite common that you will have files in your folders that are not automatically in LR.

synchronizing a folder would be the fastest way to get them into the catalog.

richardplondon schrieb
I do agree that this metadata scan ought not to be updating timestamps needlessly. Your next step may be a Feature Request.

will do that.

Report · May 27, 2019

richardplondon wrote
I can confirm the OP's behaviour - Win10, LR 8.3 (201905061635)
Raws (PEF) and XMPs in a folder.
Sync this Folder, selecting "scan metadata for changes". This scan is detected as an update action to the Catalog metadata of each image, even if no changes are found. Then if enabled, LR Auto-writes an update to the XMP file changing its modification date/time.

I can't confirm the OP's behavior using Canon 5D MKII CR2 raw files or with them converted to DNG file format. Following the above procedure I see no change. I tried it with no external changes and with adding keywords in Bridge. In all cases none of the NTFS file system date fields change as shown below Am I being dense and overlooking something or is this perhaps raw file type specific?

NOTE: Windows 10 LR 8.3

Report · May 27, 2019

Todd: did you have LR set to auto-write XMP changes out? That was what was actually making the external file dates change, AFAICT. Without that there'd be no reason they would - even if LR's internal modification timestamp for those images, had itself changed.

The OP was testing with TIFF btw, at least in one screenshot shown - not DNG, I think.

Report · May 27, 2019

richardplondon wrote
Todd: did you have LR set to auto-write XMP changes out? That was what was actually making the external file dates change, AFAICT. Without that there'd be no reason they would - even if LR's internal modification timestamp for those images, had itself

Here are my settings with 'Automatically write changes into XMP' and 'Include Develop settings in...etc.' I closed and reopened LR after making these Catalog Settings changes to make sure they were applied.

richardplondon wrote
The OP was testing with TIFF btw, at least in one screenshot shown - not DNG, I think.

In my screenshot I imported three CR2 files with XMP sidecars, three DNG, one JPEG, and one TIFF file into a new catalog. So all formats covered. No matter what I do the 'Synchronize Folder' operation does NOT change any of the NTFS date fields so I assume the file data and metadata is unchanged correct? I even tried added some keywords in Bridge and made Develop changes in ACR, which are brought into the LR catalog so I know the 'Synchronize Folder' operation is working. The dates always remain the same as before the 'Synchronize Folder' operation. I've used 'Synchronize Folder' numerous times over the years and never recall seeing files show up unexpectedly in my Backup report. And yes I use numerous TIFF files and DNG files for Panorama and HDR images so plenty of those in my catalog.

However, I only shoot with Canon cameras so perhaps that's the clue here. Try it yourself with some Canon CR2 raw files both unconverted, converted to DNG and TIFF file format. Scroll down here to download some 5D MKII CR2 files and tell me what you see: https://www.photographyblog.com/pages/reviews/reviews_canon_eos_5d_mark_ii_3.php

Report · May 27, 2019

doesn´t matter if it´s DNG or TIFF. happens with both.

In my screenshot I imported three CR2 files with XMP sidecars, three DNG, one JPEG, and one TIFF file into a new catalog. So all formats covered. No matter what I do the 'Synchronize Folder' does NOT change any of the NTFS date fields so I assume the file data and metadata is unchanged correct?

in the test i made all files where changed. but i think it was covered in the other thread that not all files are always changed.

what makes this whole issue even more strange.

if you don´t care about the files beeing changed try it with a folder that has a few hundred images in it.

my files where untouched for month if not years. maybe newly imported files will behave different.

i just did a test and cloned one of my RAW image databases from one SSD to another.

then i run synchronize folder on the root folder and around 50% of the images (~16000) were changed.

Report · May 27, 2019

richardplondon's testing used PEF raw files with XMP sidecars and was able to see the issue. Perhaps try testing with PEF raw files.

I shoot CR2 raw files with Canon 300D, 600D, 5D MKII, 6D, and G9X MKII cameras and have never seen this issue. I always look at my Backup Synchronization Comparison Prescan and have never seen any unexplained "changed files" popup.

I just did a 'Synchronize Folder' operation with 'Scan Metadata for changes' checked on a folder with over 500 CR2 raw, TIFF and DNG mixed files and then ran my backup application. The pre-synchronization file comparison scan found NO files in that folder that need updating. I can't duplicate the issue either and agree Adobe will not even look at this issue without a repeatable step-by-step process that exhibits the issue. I'm not saying it doesn't happen just that John Ellis and I can't duplicate it and we both have considerable experience troubleshooting LR issues.

Report · May 27, 2019

I can't duplicate the issue either and agree Adobe will not even look at this issue without a repeatable step-by-step process that exhibits the issue. I'm not saying it doesn't happen just that John Ellis and I can't duplicate it and we both have considerable experience troubleshooting LR issues.

the step by step was given in this thread and the other. what more do you need?

not every bug is repeatable all the time. this one is on my system ...and others as it seems.

but if adobe will not even look at it and test it on their systems... it is no wonder that so many bugs in LR and photoshop are not fixed.

edit:

i forgot to mention this.

i have a smartcollection for files that are not up to date:

the changed images are listed in this smartcollection after synchronizing.

with the 16000+ images from my last test it took a while to update them so i noticed it.

LR thinks it needs to update these images.

but then all it actually updates you can see in the screenshots of the binary compare:

Report · May 27, 2019

Sync this Folder, selecting "scan metadata for changes". This scan is detected as an update action to the Catalog metadata of each image, even if no changes are found. Then if enabled, LR Auto-writes an update to the XMP file changing its modification date/time.

I can't reproduce this behavior either. Reading this thread and the other thread, I very much doubt Adobe will pay much attention without a precise step-by-step recipe that reliably reproduces the problem.

If you can post before and after versions of a .xmp file modified by Scan Metadata For Changes, then we might get some more insight about what's going on, leading to a reliable recipe.

Report · May 27, 2019

johnrellis schrieb
Sync this Folder, selecting "scan metadata for changes". This scan is detected as an update action to the Catalog metadata of each image, even if no changes are found. Then if enabled, LR Auto-writes an update to the XMP file changing its modification date/time.
I can't reproduce this behavior either. Reading this thread and the other thread, I very much doubt Adobe will pay much attention without a precise step-by-step recipe that reliably reproduces the problem.
If you can post before and after versions of a .xmp file modified by Scan Metadata For Changes, then we might get some more insight about what's going on, leading to a reliable recipe.

you rightclick on the folder choose "synchronize foder" there are no other steps.

in the settings you need to have "write to XMP enabled" and "scan for metadata changes" checked on the synchronize windows.

If you can post before and after versions of a .xmp file modified by Scan Metadata For Changes,

you did read my post?

i have posted the changes and so have others in the other thread.

in my case there is no XMP file as the files are in TIFF format.

Report · May 27, 2019

I was hoping that Richard could upload the before and after .xmp files he was observing to Dropbox or similar. Alternatively, if you could upload to Dropbox or similar the before and after TIFF files and post the sharing links here, that would accomplish the same end. That would allow us to look in detail at the entire XMP (and other metadata) to see if that gives hints why LR was modifying the metadata.

I tried the exact steps posted and the behavior didn't occur for me, as with Todd. I wrote in that other thread in 2016:

Based on past experience, Adobe is much more likely to pay attention to problems if many people report similar symptoms or if the bug report includes a precise step-by-step recipe that makes it straightforward for someone else to reproduce the problem. There have been almost no reports about this issue in the last few years, so I think that unless you have a recipe that makes it easy to reproduce the problem, the bug report is not likely to spur Adobe to immediate action. ... In general, recipes are more likely to be reproducible if they start with a fresh catalog and involve just a few files imported into that catalog. I know from personal experience that producing such recipes is a lot of work; but to the extent that a bug report doesn't include one, it's less likely that Adobe will act on it absent many others reporting similar symptoms.
One additional suggestion: The before-and-after binary diff gives hints about what might be going on, but they're just hints. Providing before-and-after copies of the complete file would be much more useful, allowing the file to be put under the microscope. Often, providing the complete files can quickly narrow down the issue quite a bit. You can upload the before-and-after copies to Dropbox (or similar) and include the sharing links in the bug report.

I'm just giving my recommendation about how to get Adobe to pay attention based on years of experience, so please don't shoot the messenger.

Report · May 27, 2019

have you tried with images that are in the LR catalog for some time? edited with earlier versions of LR.

as you can see in the metadata of my images they where edited with versions before LR8.

after the files are changed and when i then synchronize the folders again, LR will not change them again.

that seems to be different to the issue reported in the other thread.

but when i clone on of my unchanged backup drives (for a test) then i can repeat it.

Report · May 28, 2019

On re-testing, it is hard to get the same outcome again on the same images.

I do now have a folder of images that all reflect the date and time of a folder sync, in the modification date on all the sidecar XMPs (the Raw files' dates did not change).

Within these, the field "xmp:MetadataDate" reflects the date and time of the folder sync which the OS cannot have decided to set; that must have been LR. These images received no recent deliberate edit either within LR or externally, to the best of my care. I was however viewing and re-sorting both the folder in the file browser, and the folder view in LR at the time.

I then "forced" a metadata update by text-editing an XMP externally, saving, changing text back identically, saving. LR was running at the time. I then ran a folder sync with metadata scan. This time just that image's XMP modification date was updated to the time of the sync, other images were untouched.

However viewing the text inside this one XMP, the "xmp:MetadataDate" did not show the time of the scan; it stayed as it had been. So there's a difference between the two cases.

Report · May 28, 2019

Over the years, there have been a number of releases where LR automatically updates catalog entries for existing photos incrementally in background as you do various operations (scrolling through thumbnails, editing photos). Sometimes this has generated updates to the metadata (both Library and Develop settings). That may be what's happening here, either by intentional design or not.

But without two sample before and after photos, I think it's a waste of time to spend more effort thinking about this, and certainly Adobe isn't going to pay any attention.