Bug 493535

Summary: Wish : writing sidecar files timestamp option
Product: [Applications] digikam Reporter: Jérôme DEMEULLE <jdemeulle.photo>
Component: Setup-MetadataAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED NOT A BUG    
Severity: wishlist CC: caulier.gilles, metzpinguin
Priority: NOR    
Version First Reported In: 8.5.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 8.7.0
Sentry Crash Report:

Description Jérôme DEMEULLE 2024-09-23 15:42:56 UTC 
WISH :

I would have the possibility to update the timestamp of sidecar files when modifying their metadata without changing the timestamp of image files (when I'm using writing to XMP AND image in a same process).

SOFTWARE/OS VERSIONS
Windows 10 Version 22H2 (x86_64)
Build date: 26/08/2024 13:02 (target: RelWithDebInfo)
Revision: 06628592d7d5e366601c86cd19ad92234c4bc85c
Branch: master
Comment 1 Maik Qualmann 2024-09-23 18:20:17 UTC 
Such an option could actually have an unwanted effect for you. The modification date in the DB and thus in the digiKam view would also change to the current date.

We save the most recent date, either from the image modification date or the sidecar modification date, in the database. This enables us to recognize external changes to the sidecar or image if the file size has not changed. This was an important request from many users who modify sidecars externally.

What is the problem with updating the modification date of the image and sidecar when the files have been changed?

That's what the modification date of a file is for.

Maik
Comment 2 Jérôme DEMEULLE 2024-09-23 21:30:32 UTC 
OK, I understand that this is not possible with actual timestamp usage.
My problem is that I did not want to change the timestamp of the image files and I added a sidecar to help me detect where and why my DK is stuck.
I don't know if it is really stuck or if it is very very slow. It suddenly takes over a week to update the metadata without completing it. The database also seems to be slow, but I don't know if it is slow because DK is slow or if DK is slow because the database is slow.

I also noticed that when I do large metadata updates (I have 100K files in 25 folders), it seems that updates overwrite each other because I end up with some files with no metadata at all.
And I'm not able to reproduce each times cases. It occurs some times.
I think we can close this wish, I need to find another way for my issue.