[KPhotoAlbum] crashes when using foreign database

[Andreas Schleth]

Hi,

since a few iterations of the current git master I expericence crashes
when some files in the .thumbnails (or .videothumbnails) folders have
the wrong owner or strange permissions.

This mix of owners happens quite often here, as we share our KPA
databases via NFS. So if someone imports some new images into the family
album, the new thumbnails (and images) will belong to her.

The images have rw-r--r-- ownership by default (?), so they are readable
by all (we share the same group). I have manually set the .-folders to
rwxrwxr-x, so that anybody in the users group can write.

It seems to me that KPA tries to recreate all thumbnails if the
ownership of some of these files do not match the current owner. Then it
will invariably hit some files with the orignal rw-r--r-- settings and
crash.

a) Why does KPA start rebuilding the thumbnails in first place? The
rebuild starts each time somebody else accesses the DB. It should just
take the thumbnails that are present and live with them.

b) Could we not define somewhere in the settings, how we want the
permissions to be? Right now the permissions seem to be set by some
system dependent magic.

c) I know, that the thumbnail-size is set in the .config/kphotoalbumrc -
probably differently for each user.


Alas, I did some more testing (all on a DB not owned by me) permission
changes done as root, KPA used as myself:

1. set all permissions in .thumbnails to rw-rw-r--

2. open the foreign DB.

3. ./thumbnails/thumbnailindex gets recreated by me. (why?)

4. close the DB

6. change owner back to the original: beate:users

7. change permissions to rw-r--r--:

wshome5:/home/beate/Handy-Bilder # ll .thumbnails/
insgesamt 41650
-rw-r--r-- 1 beate users 33556331 25. Mai 11:13 thumb-0
-rw-r--r-- 1 beate users  9156333 12. Okt 2020  thumb-1
-rw-r--r-- 1 beate users   310330 25. Mai 11:14 thumbnailindex

     (I was having a break inbetween)

8. open the DB again as myself and do some minor adjustments (rotate a
few images): The thumbnails vanish (as the files are not writable by me)

9. close the DB again and look at the folder:

wshome5:/home/beate/Handy-Bilder # ll .thumbnails/
insgesamt 41650
-rw-r--r-- 1 beate users 33556331 25. Mai 11:13 thumb-0
-rw-r--r-- 1 beate users  9156333 12. Okt 2020  thumb-1
-rw-rw-r-- 1 as    users   310060 25. Mai 14:24 thumbnailindex
wshome5:/home/beate/Handy-Bilder #

10. This is most unexpected: the thumbnailindex get new permissions and
new owner (me) - but I did not have write permissions on this file (only
on the folder).


I know, all this sounds a bit garbled. It is not meant to be a "real"
bug message, even if a crashreport is attached, but more to express my
general pain with the thumbnails in KPA.

I have seen some discussions about improving handling of thumbnails in
the past. Maybe one could take into account these quirks and try to
handle things differently. However, I have no solution.


My user story is:

- have a db shared between multiple users in the same group.

- the db may reside on a remote file system

- users use various PCs to access the db

- the same PC is shared by multiple users

- all users add to and edit (tag images) the db from the same or from
different PCs

- the users might have different preferences for their thumbnail size

- the same user might have different preferences on different machines,
as they have different screen sizes

- in my current setup, it takes >1h to recreate the thumbnails for 40k
images (so I don't want to do this often).


Best regards, Andreas

-------------- next part --------------
Application: kphotoalbum (v5.7.0-263-ga78553e1)

Qt Version: 5.12.7
Frameworks Version: 5.71.0
Operating System: Linux 5.3.18-lp152.75-preempt x86_64
Windowing system: X11
Distribution: openSUSE Leap 15.2

-- Information about the crash:
<Erklären Sie bitte ganz genau, was Sie machten, als das Programm abstürzte.>

The crash can be reproduced every time.

-- Backtrace:
Application: KPhotoAlbum (kphotoalbum), signal: Aborted
[KCrash Handler]
#4  0x00007fcbc7d0e420 in raise () from /lib64/libc.so.6
#5  0x00007fcbc7d0fa01 in abort () from /lib64/libc.so.6
#6  0x00007fcbc8a657fb in QMessageLogger::fatal(char const*, ...) const () from /usr/lib64/libQt5Core.so.5
#7  0x00007fcbc8a64ff1 in qt_assert(char const*, char const*, int) () from /usr/lib64/libQt5Core.so.5
#8  0x0000000000639e02 in Utilities::saveImage (fileName=..., image=..., format=0x66dbf4 "JPEG") at /home/usr/src/kphotoalbum-git/kphotoalbum/Utilities/ImageUtil.cpp:23
#9  0x0000000000622e8e in BackgroundJobs::HandleVideoThumbnailRequestJob::saveFullScaleFrame (fileName=..., image=...) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundJobs/HandleVideoThumbnailRequestJob.cpp:63
#10 0x0000000000622dc9 in BackgroundJobs::HandleVideoThumbnailRequestJob::frameLoaded (this=0x321f800, image=<incomplete type>) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundJobs/HandleVideoThumbnailRequestJob.cpp:56
#11 0x0000000000622c38 in BackgroundJobs::HandleVideoThumbnailRequestJob::execute (this=0x321f800) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundJobs/HandleVideoThumbnailRequestJob.cpp:47
#12 0x000000000061b8f7 in BackgroundTaskManager::JobInterface::start (this=0x321f800) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundTaskManager/JobInterface.cpp:35
#13 0x000000000061bf0d in BackgroundTaskManager::JobManager::execute (this=0x2a490d0) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundTaskManager/JobManager.cpp:61
#14 0x000000000061bf68 in BackgroundTaskManager::JobManager::addJob (this=0x2a490d0, job=0x321f800) at /home/usr/src/kphotoalbum-git/kphotoalbum/BackgroundTaskManager/JobManager.cpp:68
#15 0x000000000057cc7d in ImageManager::AsyncLoader::loadVideo (this=0x2b5d560, request=0x30def80) at /home/usr/src/kphotoalbum-git/kphotoalbum/ImageManager/AsyncLoader.cpp:109
#16 0x000000000057cb44 in ImageManager::AsyncLoader::load (this=0x2b5d560, request=0x30def80) at /home/usr/src/kphotoalbum-git/kphotoalbum/ImageManager/AsyncLoader.cpp:86
#17 0x000000000051e9f9 in Viewer::ImageDisplay::requestImage (this=0x2bc9cd0, info=..., priority=false) at /home/usr/src/kphotoalbum-git/kphotoalbum/Viewer/ImageDisplay.cpp:737
#18 0x000000000051d882 in Viewer::ImageDisplay::updatePreload (this=0x2bc9cd0) at /home/usr/src/kphotoalbum-git/kphotoalbum/Viewer/ImageDisplay.cpp:603
#19 0x000000000051d434 in Viewer::ImageDisplay::pixmapLoaded (this=0x2bc9cd0, request=0x30def20, image=...) at /home/usr/src/kphotoalbum-git/kphotoalbum/Viewer/ImageDisplay.cpp:565
#20 0x000000000057d5ed in ImageManager::AsyncLoader::customEvent (this=0x2b5d560, ev=0x7fcb68004e40) at /home/usr/src/kphotoalbum-git/kphotoalbum/ImageManager/AsyncLoader.cpp:230
#21 0x00007fcbc8c9499b in QObject::event(QEvent*) () from /usr/lib64/libQt5Core.so.5
#22 0x00007fcbc9ae9f2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#23 0x00007fcbc9af1540 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#24 0x00007fcbc8c64328 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#25 0x00007fcbc8c66ee7 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#26 0x00007fcbc8cc1d93 in ?? () from /usr/lib64/libQt5Core.so.5
#27 0x00007fcbbd446624 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#28 0x00007fcbbd4469c0 in ?? () from /usr/lib64/libglib-2.0.so.0
#29 0x00007fcbbd446a4c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#30 0x00007fcbc8cc13af in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#31 0x00007fcbc8c6257a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#32 0x00007fcbc8c6b780 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#33 0x000000000048f75a in main (argc=3, argv=0x7ffdec4e4d98) at /home/usr/src/kphotoalbum-git/kphotoalbum/main.cpp:162
[Inferior 1 (process 24124) detached]