XMP files updated despite no change

[RawConvert]

Describe the bug

If whilst working in DT on a raw file I go into the darktable then back to lighttable without making any changes, in fact not doing anything except pressing "L", then the XMP is updated, as shown by its date/time in Ubuntu's file manager. Repeatedly moving between lighttable and darktable for the same raw causes repeated updates. Also, whilst in the darktable, the XMP is updated every time I click "compress history stack".
All this happens on various raws I've tried. DT 5.0.0 appimage
It does not happen with the 4.8 appimage.
Sample XMP renamed to .txt is attached.
Discussion available here - https://discuss.pixls.us/t/xmp-files-updated-despite-no-change/47370/11

Steps to reproduce

as above

Expected behavior

I would expect the XMP not to be updated

Logfile | Screenshot | Screencast

_6D_13536.CR2.txt

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

Darktable-5.0.0-x86_64.AppImage

What OS are you using?

Linux

What is the version of your OS?

ubuntu 22.04

Describe your system?

core i7, 32Gb ram, no GPU card

Are you using OpenCL GPU in darktable?

No

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[RawConvert]

Here are some files showing the updating.
The procedure was as follows using a play raw boat image which already has an XMP. This is a basic default xmp with some extra exposure. Steps as follows -
0. save xmp as boatXmp1 and note time - 15:38 is the xmp time in file manager

1. start dt -d perf
2. doubleclick and then note time - should be same - yes, 15:38
3. wait, press L then note time - s/be different - yes, 15:45
4. save xmp as boatXmp2
5. wait, doubleclick
6. wait, press L - time is now 15:47, changed
7. save xmp as boatXmp3
8. quit DT
   Attached are the XMPs and a copy of the Terminal window. The raw (CR2) is too big to upload, you can get it here -
   https://discuss.pixls.us/t/storm-darragh-a-bit-breezy/46945

boatXmp3.txt
boatXmp2.txt
boatXmp1.txt
boat-terminal-log.txt

[paperdigits]

Are you sure those files are different? They show no differences at all for me. Can you provide the diff?

[RawConvert]

If they are the same, it looks like DT is re-writing the same XMP each time, hence the timestamp advancing each time, which is the issue I reported. I don't think it should be re-writing the same file, and it wasn't doing this in 4.8.

[paperdigits]

If you're really going from an XMP touched in 4.8 to 5.0, then you should have new schema in the XMP file. The files should not be exactly the same, at least the date modified should be different.

Are you sure you're not looking at access time in your file manager?

[RawConvert]

See the screen jpeg above, it says it's the modified time.
Pls note, the test I've shown is not about going from 4.8 to 5, it all took place in 5, as the terminal log shows, and I made sure the xmp I started with, boatXmp1, was produced by 5.0, not 4.8.
Remember I reported one case in pixls where the file lengthened - this was perhaps due to taking a 4.8 xmp into DT 5.0, but I can't remember the details now.

[wpferguson]

I tested on 5.1. The first time I open in darkroom the XMP updates. Stop/start darktable, reopen same image in darkroom, stop darktable, no update.

[RawConvert]

It sounds like it's been quickly fixed, which is great. I'll try an appimage at some point if there are weeklies or whatever. Are you a dev? - is there a "pull request" or anything covering the fix?

[RawConvert]

Mmmm @wpferguson I've just re-read your post, I think you are saying you closed DT whilst in the darktable/darkroom. I think it's when you go back to lighttable that the XMP is updated/re-written. Maybe you could double-check pls?

[wpferguson]

Yes, when I return to lighttable, the XMP is updated. I saved an earlier copy of it and diff'ed with no differences.

[RawConvert]

Ok so this is NOT fixed. There may be no differences in the two XMPs but that's not the point. You get a file with a later timestamp just because you view something you worked on last week, so a) it's misleading b) DT is doing unnecessary file operations c) you no longer have the confidence that the XMP and the JPEG are consistent.

[ptilopteri]

* Andrew ***@***.***> [01-03-25 15:49]:

Ok so this is NOT fixed. There may be no differences in the two XMPs but that's not the point. You get a file with a later timestamp just because you view something you worked on last week, so a) it's misleading b) DT is doing unnecessary file operations c) you no longer have the confidence that the XMP and the JPEG are consistent.

I can confirm on master, 5.1.0+36~ge932ddb438 openSUSE Tumbleweed 20250102

…

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

[TurboGit]

I haven't looked at the code but this is probably hard to fix. I suppose that when leaving the darkroom we write the XMP for whatever change has been made in any module. Capturing a change in any module is probably not trivial to avoid this write.

[RawConvert]

@TurboGit , ok but to the best of my knowledge this is new behaviour. I tested this on the 4.8 appimage and the XMPs don't get updated/re-written when you go in and out of the darkroom without doing anything. I think it's been like this for years!

[wpferguson]

@TurboGit I think this is mine. When I made the change to write darktable tags to the XMP I "made it work" without fully understanding the impact. Let me look at it and see if I can find a fix that satisfies my requirements and fixes this problem.

[wpferguson]

Are you a dev?

Sometimes... Other times I'm an accident that found a place to happen.

[RawConvert]

Haha well that's not ideal for a software developer, but at least you're not a brain surgeon! (Or are you?!)

[wpferguson]

I think every dev has done something that "seemed like a good idea at the time" and it came back to bite them. The really good devs have lots of teeth marks but not (m)any recent ones.

[victoryforce]

I think every dev has done something that "seemed like a good idea at the time" and it came back to bite them. The really good devs have lots of teeth marks but not (m)any recent ones.

Exactly!

[RawConvert]

Thank you