Bug 122653 - file-dialogue claims that pictures are not on the local-storage, yet they are
Summary: file-dialogue claims that pictures are not on the local-storage, yet they are
Alias: None
Product: digikam
Classification: Unclassified
Component: Database-Media (show other bugs)
Version: 0.10.0
Platform: openSUSE RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2006-02-24 19:26 UTC by S. Burmeister
Modified: 2017-07-26 05:13 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Note You need to log in before you can comment on or make changes to this bug.
Description S. Burmeister 2006-02-24 19:26:20 UTC
Version:           0.8.1 (using KDE KDE 3.5.1)
Installed from:    SuSE RPMs
OS:                Linux

I select some pictures from within an album and drag them to another to move them there. I get the dialogue stating that the picture already exists. Yet the pictures are not shown, but instead there is the notice that they are not on a local-storag, which is wrong, as they are in my home-dir, which is on a local hdd.
Comment 1 S. Burmeister 2006-06-21 20:26:51 UTC
Can nobody confirm this?
Comment 2 Mikolaj Machowski 2006-06-22 16:21:37 UTC
Yes, it happens for me also.
Comment 3 caulier.gilles 2006-07-25 19:04:43 UTC
Yes, of course i can confirm this bug.

I suspect than camera picture download bug #126427 is the same problem.

After investiguations, the problem is relevant of KURL construct by digiKam and passed to KDE kio-slave to copy/move the pictures.

The KURL is given by PAlbum class and use "digikamalbum:/" protocol witch is unkown by KDE kio-slave. This is why the dialog cannot found the image to display.

Not yet tested, but if i force in digiKam to use "file:/" protocol with kurl passed to KDE kio-slave, all will work fine.

Marcel, i would have your viewpoint about "digikamalbum:/" protocol: 

- The error come from PAlbum class where a full compatible kurl method need to be added, especially for KDE kio-slave...


- The error come from kio-slave protocol installation witch is not properlly installed and reconized by KDE...


- Something is missing in digikamalbum kio-slave to be compliant with KDE rules.

Comment 4 Marcel Wiesweg 2006-07-25 22:59:01 UTC
AlbumFolderView::contentsDropEvent will call DIO::copy with kioURLs.
DIO::copy will call KIO::copy.

KIO::copy will check if the dest exists, it does, so I think it is the KDE libs that will popup the overwrite dialog. Of course, it is unknown to KDE libs that digikamalbums:/ is actually a local file. Don't know how to change that.

Then, KDE libs will load the proper kioslave, and kio_digikamalbums::copy will get called. You have the debug statement from that method in your ~/.xsession-errors.

Then the copy method will somewhere return with KIO::ERR_ACCESS_DENIED, and the error message is sent to digikam.
So we have to fix the ioslave.

Or, some not-thought-through ideas:
- in albumfolderview, use normal file:/ URLs and afterwars do the same as in ImageWindow::saveAsIsComplete. Race-condition proof?
- use ForwardingSlaveBase for all file-related stuff in our ioslave - a pity, it's only available for KDE 3.4.
Comment 5 Marcel Wiesweg 2006-09-18 22:16:21 UTC
SVN commit 586141 by mwiesweg:

Provide the UDS_LOCAL_PATH entry.
Now the KDE replace file dialog will no longer think digikamalbums:/ is a remote file.

CCBUG: 122653

 M  +5 -1      digikamalbums.cpp  

--- trunk/extragear/graphics/digikam/kioslave/digikamalbums.cpp #586140:586141
@@ -1149,7 +1149,11 @@
     atom.m_uds = KIO::UDS_NAME;
     atom.m_str = QFileInfo(path).fileName();
+    atom.m_uds = KIO::UDS_LOCAL_PATH;
+    atom.m_str = path;
+    entry.append(atom);
     return true;
Comment 6 Marcel Wiesweg 2006-09-18 22:20:14 UTC
When I tested this, I got an error message, (#4), but now it seems to me this bug is only about the "not on local storage" message. This is fixed now, so I close this.
Comment 7 Marcel Wiesweg 2006-11-15 19:05:50 UTC
SVN commit 605173 by mwiesweg:

Revert fix for bug #122653, as a temporary fix for bug #137282

CCBUG: 137282, 122653

 M  +7 -0      digikamalbums.cpp  

--- trunk/extragear/graphics/digikam/kioslave/digikamalbums.cpp #605172:605173
@@ -1151,11 +1151,18 @@
     atom.m_str = QFileInfo(path).fileName();
+    /*
+    // If we provide the local path, a KIO::CopyJob will optimize away
+    // the use of our custom digikamalbums:/ ioslave, which breaks
+    // copying the database entry:
+    // Disabling this as a temporary solution for bug #137282
+    // This code is intended as a fix for bug #122653.
 #if KDE_IS_VERSION(3,4,0)
     atom.m_uds = KIO::UDS_LOCAL_PATH;
     atom.m_str = path;
+    */
     return true;
Comment 8 Marcel Wiesweg 2006-11-15 19:07:27 UTC
Reopening, see comment #7
Comment 9 caulier.gilles 2007-12-04 07:57:49 UTC

Do you know a new issue for this file ?

Comment 10 Marcel Wiesweg 2007-12-04 18:31:32 UTC
I have not tried it for KDE4, for KDE3, the situation did not change as far as I see...
Comment 11 caulier.gilles 2008-12-04 15:41:29 UTC

What news with 0.10.0 ? It still valid ?

Comment 12 Marcel Wiesweg 2008-12-04 23:41:20 UTC
Yes this is still valid. We can re-analyze if we have other means to fix this for KDE4 of course, I dont know currently.
Comment 13 Marcel Wiesweg 2008-12-11 19:07:09 UTC
*** Bug 177500 has been marked as a duplicate of this bug. ***
Comment 14 Marcel Wiesweg 2008-12-11 19:08:11 UTC
I promote this bug to 0.10. We can see if we find a solution with KDE4, but it's difficult as the relevant dialog comes from kdelibs directly.
Comment 15 Marcel Wiesweg 2009-01-04 12:51:40 UTC
*** Bug 179585 has been marked as a duplicate of this bug. ***
Comment 16 Andi Clemens 2009-07-02 22:43:00 UTC
Still not working (and maybe never will).
You get the "remote src" labels and when you click them, the thumbnail will appear.
Maybe we need to write a "real" slave for this, not only a wrapper, like here:

But then again I don't know if you get the dialog (properly yes).

Comment 17 Andi Clemens 2009-07-02 22:54:39 UTC
Hmm but why is it even working when I click the label?
If this is possible, it should also be possible to display the thumbnail in the first place, right?

Comment 18 Marcel Wiesweg 2009-07-03 16:36:17 UTC
The problem is in the depth of KIO, where our requests are identified as "remote" because the protocol is unknown and no UDS_LOCAL_PATH is provided.

The ioslave is not needed as much as in autumn of 2006, the fix from #5 may in fact be applicable now again.
Should we dare it?
Comment 19 Andi Clemens 2009-10-22 11:38:51 UTC
*** Bug 211426 has been marked as a duplicate of this bug. ***