Created attachment 114391 [details] Suggested patch As a user I would expect that Digikam during startup would rescan images when following settings are enabled: - "Update file timestamp when files are modified" - "Rescan file when files are modified" - "Write to sidecar files (Write to XMP sidecar only) But since the only the sidecar file is modified, no changes will be detected for those affected images during startup. A suggested solution might be that when Digikam saves metadata only to the sidecar file, also, the timestamp of the image file is updated. I added a suggested patch that would implement the above.
I think this should happen on the scanner side, i.e. given those settings the scanner should check the sidecar timestamp and rescan if it changed. Modifying the timestamp on files that weren't actually changed is not ideal (e.g. for sync/backup tools).
I went for a solution that was easy enough to implement. I'm not sure if any data for sidecar files like, hash, size or modification times are saved to the database? I agree that the changing timestamps on files that are not actually changed is not ideal.
This is part of bug 339342 and bug 380341. In fact, I have already thought of the same solution as Kristian. But I absolutely agree with Simon that the modification date should not be changed if the file is unchanged. However, the modification date of the sidecar file is not in the database. It would be necessary to add a column for the modification date of a sidecar file in the Images table of the database. Maik
I'm using my patch as a work-around for now. Sync'd metadata is a bit more important to me, than the significant drawback of increased backup times.
If you don't mind. I can try to have a go at suggesting a new patch, where the modification timestamp of the sidecar file is stored in the database (as Maik suggested) and used. I guess it will take me a week to do that.
Gilles, how do you see that? Add additional modification date of the sidecar file in the DB? Or adjust the file modification date of the image file? I do not see another solution. Maik
Maik, Your last Q is for me ??? Gilles
Yes, Gilles. But I have another idea. If writing is only activated to sidecar, the modification date of the sidecar file will be written to the DB instead of the image. That would save us any changes to the DB. Maik
Maik, Yes, this last idea is sound better. So the file modification time-stamp in DB is a resume of item or xmp sidecar change. One entry in DB for both. Right ? What's happen if image change and not xmp sidecar, and if we write to xmp side car only ? This case cannot be managed ? Gilles
(In reply to caulier.gilles from comment #9) > Maik, > > Yes, this last idea is sound better. So the file modification time-stamp in > DB is a resume of item or xmp sidecar change. One entry in DB for both. > Right ? Yes exactly. > What's happen if image change and not xmp sidecar, and if we write to xmp > side car only ? This case cannot be managed ? If digiKam changes the image data also metadata will be written, that's ok. But if the image is changed externally, we would not notice, because we only look for the sidecar. Backup excepted, the solution of Karl is probably the best. Maik
How about this: - If digiKam modifies either the main file or the sidecar, update the database's timestamp column to match - If another program modifies *either* of those files, digiKam should reread the image and update the database timestamp That is, ISTM that the timestamp column is trying to indicate when the conceptual "image" entity last changed -- more specifically, when its discrete, out-of-database representation changed. Supposing that's correct, whether the representation consists of one file or two is beside the point. (Then again, I don't know what other uses digiKam makes of that column, and whether any of those would conflict with this idea.)
I do not know if this is your suggestion. But save the current date in the DB, whether image or sidecare is the solution. Karl's solution does not work with third-party programs. Now we can check if there is a new modification date and start a scan. Maik
(In reply to Maik Qualmann from comment #12) > I do not know if this is your suggestion. I believe you and I are saying the same thing: if digiKam changes either the image file or its sidecar (or both), update the last-modified-time column in the database. (I agree that changing the other file's file-system last-modified-date should be avoided if possible.) > Now we can check if there is a new modification > date and start a scan. Yes. I guess I was mostly responding to gilles's comment: > What's happen if image change and not xmp sidecar, and if we write to xmp side > car only ? This case cannot be managed ? If digiKam compares the database timestamp against *both* files' change dates, this stops being a problem. I.e. if either file is newer than the database timestamp, reread. Thus, if somebody else modifies the original file, digiKam will notice that -- even if digiKam itself is configured to only ever modify the sidecar.
Created attachment 114920 [details] modificationDate.patch I think this is the solution. It works very well here. Kristian, can you also test the patch please? Maik
Created attachment 114931 [details] Old metadata remains after file is re-scanned Hi Maik, I think your solution looks really good. I tested it, and the re-scanning part works well. However, it seems that the old metadata is not discarded from the digikam database. This means that changes made in a sidecar file, will show up, which is good. But the old data, that was replaced, or removed from the sidecar file, is still displayed by digikam. This is how I tested it. ======================== 1) Start digikam in an empty folder: digikam --database-directory <empty folder> 2) When digikam asks for a collection, point to a fresh folder of images. No sidecar files exists. 3) Make sure settings are: - "Update file timestamp when files are modified" - "Rescan file when files are modified" - "Read from sidecar files" - "Write to sidecar files - "Write to XMP sidecar only" 4) Assign a face tag XXX to some image 5) Close digikam 6) Open the sidecar file in a text editor, replace the all XXX to YYY, save and close. 7) Restart digikam Expected results ================ Image will now display only YYY Actual results ================ Image displays both XXX and YYY
This is an old behavior that metadata is only updated and added to the DB. For users who only store the metadata in the DB and not in the images/sidecar. In digiKam-6.0.0, there is a new option to enable "Clean-up Metadata...", where you can also enable re-reading of the metadata. Maik
But then all is fine!
Git commit 9c77203fdc10cd59aa0ba645ab3fde7f774dbaf2 by Maik Qualmann. Committed on 13/09/2018 at 19:47. Pushed by mqualmann into branch 'master'. store as modification date always the most recent from the image or the sidecar Related: bug 398331, bug 380341, bug 339342 FIXED-IN: 6.0.0 M +5 -2 NEWS M +14 -1 core/libs/database/collection/collectionscanner.cpp M +14 -1 core/libs/database/item/imagescanner.cpp https://commits.kde.org/digikam/9c77203fdc10cd59aa0ba645ab3fde7f774dbaf2