Bug 325447 - digiKam doesn't copy pictures to Samba share mounted with autofs
Summary: digiKam doesn't copy pictures to Samba share mounted with autofs
Status: RESOLVED NOT A BUG
Alias: None
Product: digikam
Classification: Applications
Component: Import-PostProcessing (show other bugs)
Version: 3.4.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-30 03:41 UTC by Jesse TeKrony
Modified: 2022-01-10 16:00 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse TeKrony 2013-09-30 03:41:11 UTC
I have a samba share mounted with autofs. I have set the uid and gid so I have proper access to the directory and I am able to create/delete files. However, when attempting to import pictures, the process ends almost instantly and no pictures are copied, but subdirectories for date-based subalbums are created. I end up with my sambe share full of empty folders.

I am also sure that autofs has actually mounted the directory before I attempt to import the pictures.

I have had success in the past mounting the share using cifs in /etc/fstab, but I find that this slows down the boot process considerable and autofs is a much more slick solution.

(On a side note, is digiKam still unable to trigger the autofs automount at application startup? I don't mind putting an 'ls <share>' in the autostart settings, but it would be nice if I didn't have to. In fact, the website still states that mounted shares don't work at all.)

Reproducible: Always

Steps to Reproduce:
1. Ensure samba share is mounted by autofs and you have read/write access
2. Launch digiKam and create a new album pointing to the share
3. Attempt to import pictures to the share
Actual Results:  
The process instantly completes and no pictures are copied, however directories are created based on subalbum rules.

Expected Results:  
Pictures should have been copied to the share directory.
Comment 1 Jesse TeKrony 2013-09-30 03:43:01 UTC
One more thing that I might add is that digikam doesn't log anything to stdout about this.
Comment 2 caulier.gilles 2013-09-30 05:08:45 UTC
digiKam delegate all copy sttuff to network device to KDE kioslave interface. You must hack debug messages from KIOSLave :

http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves

Gilles Caulier
Comment 3 Jesse TeKrony 2013-09-30 17:56:54 UTC
"You can start klauncher in such a way that slaves for a certain protocol (the first parameter of KIO::SlaveBase() constructor of the slave class) are started in debug mode."

What protocol does digiKam use?
Comment 4 Jesse TeKrony 2013-09-30 19:45:10 UTC
Using some bash-fu to search the source code gives me some results for "KIO::SlaveBase", but I can't seem to find anything indicating the protocol. (My knowledge of C++ is very basic)

digikam-3.4.0/core/libs/database/imagelisterreceiver.cpp:125:ImageListerSlaveBaseReceiver::ImageListerSlaveBaseReceiver(KIO::SlaveBase* slave)
digikam-3.4.0/core/libs/database/imagelisterreceiver.cpp:156:ImageListerSlaveBasePartsSendingReceiver::ImageListerSlaveBasePartsSendingReceiver(KIO::SlaveBase* slave, int limit)
digikam-3.4.0/core/libs/database/imagelisterreceiver.cpp:173:    ImageListerSlaveBaseGrowingPartsSendingReceiver(KIO::SlaveBase* slave, int start, int end, int increment)
digikam-3.4.0/core/kioslave/digikamalbums.cpp:112:// ------------------------ Implementation of KIO::SlaveBase ------------------------ //
digikam-3.4.0/core/kioslave/digikamsearch.cpp:52:    explicit DuplicatesProgressObserver(KIO::SlaveBase* slave) : m_slave(slave) {}
digikam-3.4.0/core/kioslave/digikamsearch.cpp:65:    KIO::SlaveBase* m_slave;
Comment 5 Jesse TeKrony 2013-09-30 22:16:39 UTC
After fiddling around with the debugging settings a bit, I can see errors now:
digikam(24165)/digikam (core) Digikam::UMSCamera::downloadItem: Failed to open dest file for writing:  "/var/shares/pictures/2008_11/.digikam-camera-tmp1-24165Picture1.jpg" 
digikam(24165)/digikam (core) Digikam::UMSCamera::downloadItem: Failed to open dest file for writing:  "/var/shares/pictures/2008_12/.digikam-camera-tmp1-24165Picture2.jpg" 
digikam(24165)/digikam (core) Digikam::UMSCamera::downloadItem: Failed to open dest file for writing:  "/var/shares/pictures/2008_12/.digikam-camera-tmp1-24165Picture3.mov" 
...
Comment 6 Jesse TeKrony 2013-10-01 03:04:05 UTC
I have also found that mounting using cifs in /etc/fstab doesn't work with digiKam either. I have gotten this to work in the past, but it seems broken now.
Comment 7 caulier.gilles 2014-09-01 08:18:59 UTC
Jesse,

This file still valid using last digiKam 4.2.0 ?

Gilles Caulier
Comment 8 caulier.gilles 2016-07-04 20:10:25 UTC
This file still valid using digiKam 5.0.0 ?

Gilles Caulier
Comment 9 caulier.gilles 2016-11-25 06:55:55 UTC
This problem still reproducible using last DK 5.4.0 bundle ?

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

Gilles Caulier
Comment 10 caulier.gilles 2020-08-03 05:02:48 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 11 caulier.gilles 2022-01-10 16:00:49 UTC
No feedback. Closed...