Discussion:
[digikam] [Bug 397340] New: Update image file timestamps if metadata is written to sidecar file
(too old to reply)
Kristian Karl
2018-08-10 12:29:54 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Bug ID: 397340
Summary: Update image file timestamps if metadata is written to
sidecar file
Product: digikam
Version: unspecified
Platform: Other
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Metadata-Sidecar
Assignee: digikam-bugs-***@kde.org
Reporter: ***@gmail.com
Target Milestone: ---

Created attachment 114391
--> https://bugs.kde.org/attachment.cgi?id=114391&action=edit
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.
--
You are receiving this mail because:
You are watching all bug changes.
Simon
2018-08-10 12:34:12 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Simon <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #1 from Simon <***@gmail.com> ---
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).
--
You are receiving this mail because:
You are watching all bug changes.
b***@kde.org
2018-08-10 12:37:47 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Update image file |Update image file
|timestamps if metadata is |timestamps if metadata is
|written to sidecar file |written to sidecar file
| |[patch]
CC| |***@gmail.com
--
You are receiving this mail because:
You are watching all bug changes.
Kristian Karl
2018-08-10 13:16:25 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #2 from Kristian Karl <***@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-08-10 17:46:33 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #3 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-08-12 18:46:22 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #6 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Kristian Karl
2018-08-12 17:55:32 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #4 from Kristian Karl <***@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
Kristian Karl
2018-08-12 18:10:53 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #5 from Kristian Karl <***@gmail.com> ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
b***@kde.org
2018-08-13 04:13:29 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #7 from ***@gmail.com ---
Maik,

Your last Q is for me ???

Gilles
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-08-13 04:59:45 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #8 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
b***@kde.org
2018-08-13 07:58:44 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #9 from ***@gmail.com ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-08-13 12:56:13 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #10 from Maik Qualmann <***@gmail.com> ---
(In reply to caulier.gilles from comment #9)
Post by b***@kde.org
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.
Post by b***@kde.org
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
--
You are receiving this mail because:
You are watching all bug changes.
Eric
2018-09-12 18:39:30 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Eric <pub08-***@davor.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |pub08-***@davor.org

--- Comment #11 from Eric <pub08-***@davor.org> ---
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.)
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-09-12 19:55:46 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #12 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Eric
2018-09-12 20:45:45 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #13 from Eric <pub08-***@davor.org> ---
(In reply to Maik Qualmann from comment #12)
Post by Maik Qualmann
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.)
Post by Maik Qualmann
Now we can check if there is a new modification
date and start a scan.
Yes.
Post by Maik Qualmann
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.
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-09-12 20:58:02 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #114391|0 |1
is obsolete| |

--- Comment #14 from Maik Qualmann <***@gmail.com> ---
Created attachment 114920
--> https://bugs.kde.org/attachment.cgi?id=114920&action=edit
modificationDate.patch

I think this is the solution. It works very well here. Kristian, can you also
test the patch please?

Maik
--
You are receiving this mail because:
You are watching all bug changes.
Kristian Karl
2018-09-13 13:09:32 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #15 from Kristian Karl <***@gmail.com> ---
Created attachment 114931
--> https://bugs.kde.org/attachment.cgi?id=114931&action=edit
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
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-09-13 14:18:02 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #16 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Kristian Karl
2018-09-13 14:27:59 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

--- Comment #17 from Kristian Karl <***@gmail.com> ---
But then all is fine!
--
You are receiving this mail because:
You are watching all bug changes.
Maik Qualmann
2018-09-13 19:51:21 UTC
Permalink
https://bugs.kde.org/show_bug.cgi?id=397340

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Latest Commit| |https://commits.kde.org/dig
| |ikam/9c77203fdc10cd59aa0ba6
| |45ab3fde7f774dbaf2
Status|UNCONFIRMED |RESOLVED
Version Fixed In| |6.0.0

--- Comment #18 from Maik Qualmann <***@gmail.com> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
Loading...