Bug 377249 - Moving a photo to album in different collection deletes its folder
Summary: Moving a photo to album in different collection deletes its folder
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Mysql (show other bugs)
Version: 5.3.0
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-05 17:51 UTC by Robert V.
Modified: 2020-08-05 21:29 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.1.0


Attachments
Digikam 5.5.0 dump, albums, config (145.92 KB, application/x-7z-compressed)
2017-05-08 19:42 UTC, Robert V.
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert V. 2017-03-05 17:51:06 UTC
As I started to use digikam on my notebook with limited disk space, I have created more collections. One is local, the other one is on removable hard drive. When I move a photo from local collection to an album on the collection on the removable drive, it disappears. I use a MySQL DB backend. The album referrence in DB becomes NULL.

Things to reproduce:
1. have a photo in an album in the local collection (if you search the photo in DB now using something like SELECT * FROM `Images` WHERE `name` = 'photoname.jpg' - the album field will be filled with ID of the local album)
2. right click, Move to Album
3. select an album in the collection on the removable drive, OK

The photo is not in the original album anymore. And it is not in the target album.

If I list contents of the target directory, I can clearly see that the image is there.

If I run the query SELECT * FROM `Images` WHERE `name` = 'photoname.jpg' - the album field is NULL

If I try to Refresh the target album, it finds no new photos, the target album remains empty.
Comment 1 Maik Qualmann 2017-03-21 20:49:37 UTC
I cannot reproduce this problem with an internal MySQL server. The image is correctly moved to an external collection on a USB drive and appears in the album.

Maik
Comment 2 Robert V. 2017-03-26 21:50:04 UTC
I have upgraded my Digikam installation to v5.5.0 from an unofficial ebuild and I am unable to reproduce the issue anymore. Even the moved images that were missing were now detected (but I have some invalid entries in the database - the images with null album referrence from v5.3.0). Is there a DB cleanup procedure? Is it safe to delete them?

Robert
Comment 3 caulier.gilles 2017-03-27 06:38:37 UTC
yes 5.5.0 come with a DB cleanup tool in Maintenance dialog.

With 5.5.0 sqlite is supported.

For 5.6.0, Mysql will be supported.

Before to run it, just make a DB backup, to be sure.

Gilles Caulier
Comment 4 caulier.gilles 2017-03-27 06:39:30 UTC
If you use Mysql, the first 5.6.0 AppImage for Linux is available here :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 5 Robert V. 2017-05-08 19:41:46 UTC
Now I Did reproduce it. Actually it happens only when moving to some AlbumRoot. As I see it, it happens whenever I move an album to an AlbumRoot that has identifier same as other AlbumRoot with lower ID. I attach a SQL dump, digikam config and the Collections. If you move the test album from Photos_t to Photos_ttt, it should disappear.
Comment 6 Robert V. 2017-05-08 19:42:26 UTC
Created attachment 105396 [details]
Digikam 5.5.0 dump, albums, config
Comment 7 caulier.gilles 2017-12-13 22:42:43 UTC
With next 5.8.0 release Mysql support have been well improved and a lots of
bugs fixed.

Please test with pre release 5.8.0 bundles that we provide and give us a
feedback

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier
Comment 8 caulier.gilles 2020-08-02 12:38:45 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 9 Robert V. 2020-08-05 18:01:48 UTC
(Un)fortunately, I did not encounter this behaviour after upgrading Digikam.
Comment 10 caulier.gilles 2020-08-05 21:29:03 UTC
Thanks for the feedback