[Digikam-devel] [Bug 233222] Thumbnails displayed are from incorrect images

[Marcel Wiesweg]

https://bugs.kde.org/show_bug.cgi?id=233222





--- Comment #25 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-05-25 18:37:44 ---
> Question is: When will Digikam discover that
> the file size has changed? Ok, at least at next rescan. But what if I open up
> Digikam, new pics are scanned in, possibly with wrong filesize and thumb again,
> and then I open one of the new albums and click on a picture. Is this
> sufficient?

For now, pressing F5 (Refresh) should do the trick.

> Additional comments and thoughts:
> 1. Is it in any way possible to find out whether a certain file is currently
> opened for write operations by another process? I didn't find anything like
> that in "man 2 stat", but only had a short look. One other solution could be
> that Digikam opens each _new_ file for writing and immediatly closes it again
> without modification. As long as only one process may open each file for
> writing at a time, this would result in the appropriate error code that could
> be checked. Of course, there are (at least) two preconditions: mtime of the
> file must not be modified, and it mustn't slow down Digikams scanning
> operation. And, of course, this cannot be applied to read-only file systems
> (different error code?).

I have also researched this problem on the net, and your suggestion can be
found there. I'm not completely convinced that it will work, maybe we try. I
dont know about modification date in that case.

> 
> 2. Assume we have a file with 0 bytes length and name x.jpg. Even with the
> version patched by Marcel this will result in a DB entry without uniqueHash and
> with wrong thumbnail. Especially the latter is cleary an error and just mustn't
> happen. What about a special treatment for corrupt jpg files (or whatever other
> picture format)? I think the thumbnail error could be avoided if every file,
> even empty ones, get a uniqueHash. Though I don't know how unique this will be
> for empty files... at least this way they could perhaps point to a special
> thumbnail indicating "this file is corrupt".

Yes, a file of size 0 should be a clear warning sign to the scanning process.
We need some mechanisms in place there to handle such problems. (for whatever
reason, this problem never came up over the years. I was wondering why but
accepted that it worked. Obviously, it does not)

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.