I thought I understood this process as it is well documented in the manual, but my system does not behave as I expect it to so, clearly, I haven’t understood it.
I replaced the xmp for an image with a version which was created at an earlier date but which contains tag information which the later version does not. I have preferences set to ‘look for updated xmp files on startup’ activated and ‘write sidecar file for each image’ set to ‘never’, and, in another test, to ‘after edit’. In no test so far has the updated tag information, which I can see in the XML, displayed in lighttable and dt does not notify me of a mismatch between the time stamp of the .xmp file and the time information held in the database. However, if I reimport the file, using the ‘add to library’ import option, then lighttable displays the expected tag information.
Is this the expected behaviour? I was not expecting that I would have to re-import the image.
dt only checks for updated xmps on startup. And it will never check for updated xmps during a run.
If dt finds modified xmp files on startup, it will show a dialog. I know that that works as expected for changed tags.
Anyway, modifying an xmp while dt is running is a bit risky, if there’s any chance dt will want to write to that sidecar as well (even if it writes to the sidecar after the other program closed it; as dt doesn’t check for changes, it’ll discard any changes).
@LateJunction : touch is a Unix / Linux command that simply updates the last modification time of files to the current moment. touch *xmp
would update the modification timestamp for all sidecars.
This is the explanation/clarification I was hoping for, as it more fully explains (in my mind) the way my install behaves.
My logic was as I had designed it: the older .xmps contained more information than the newer ones (as they were created on different systems based on a single image)
Yes, I understood that - at no time have I replaced xmps while dt was running - I always closed it before overwriting an .xmp and then restarted afterwards. Obviously, as explained to me by @paperdigits, the .xmp update check did not see earlier xmps as updates.