Bug 294904

Summary: Drag and drop from Ark to Folder View extracts to wrong folder if the latter is set to "Display the Desktop Folder"
Product: [Applications] ark Reporter: Mahendra Tallur <mahen>
Component: generalAssignee: Ignat Semenov <i.semenov.kde>
Status: RESOLVED FIXED    
Severity: normal CC: elvis.angelaccio, hein, i.semenov.kde, illumilore, kyklops, mahen, nitanovidiu, post, szx, virgolus
Priority: NOR    
Version: 2.19   
Target Milestone: ---   
Platform: Ubuntu   
OS: Linux   
Latest Commit: Version Fixed In:

Description Mahendra Tallur 2012-02-27 07:31:13 UTC
Version:           unspecified (using KDE 4.8.0) 
OS:                Linux

When dragging & dropping a file from an archive, in Ark, to a folder view plasmoid (either the whole desktop, or, a folder view plasmoid), the file is extracted to the wrong directory if the folder view is set to display the Desktop Folder.

In the Folder View configuration, there are 3 choices : 1) display the Desktop folder 2) display the place... 3) display the folder... This bad behaviour only occurs in the first case. If I select "Display the Place -> Desktop" or "Display the Folder -> /home/xxx/Desktop", it *does* work properly.

2 remarks :

- In my case, this is not "/home/xxx/Desktop" but "Bureau" (fr. localisation)
- When the file is not extracted to the Desktop, in the 1st case, it is actually extracted to /home/xxx/Documents

Reproducible: Always

Steps to Reproduce:
- Create a Folder View Plasmoid
- In its configuration choose the first option (display the Desktop folder)
- Open an archive in Ark (and not in Dolphin)
- D&D any file from Ark to the plasmoid

Actual Results:  
- The file is extracted to Documents/ instead of Desktop/

Expected Results:  
- The file should be extracted to Desktop/

Kubuntu 11.10
Ark 2.18
KDE 4.8.0
French locale
Comment 1 Raphael Kubo da Costa 2012-04-11 18:34:54 UTC
I've managed to reproduce it here with en_US.UTF-8 as my locale. I don't have a "Documents" folder, so the file I dragged into folder view ended up in my $HOME.

CC'ing Ignat Simenov, who's been working on the folder view code, i case he's got something to say.
Comment 2 Raphael Kubo da Costa 2012-08-08 05:40:36 UTC
*** Bug 304768 has been marked as a duplicate of this bug. ***
Comment 3 Raphael Kubo da Costa 2012-09-14 08:54:55 UTC
*** Bug 306775 has been marked as a duplicate of this bug. ***
Comment 4 Mahendra Tallur 2013-03-26 21:11:16 UTC
Hi !

This bug still occurs in KDE 4.10.1 (Kubuntu 12.10). That is to say : when D&D a file from Ark to the "folder view" plasmoid showing the Desktop place, it is copied instead to my ~/ folder.

Cheers !
Comment 5 Ovidiu D. Niţan 2013-04-25 10:21:22 UTC
I can confirm this still happens in 4.10.2. Still my files are extracted in ~/ instead of Desktop.
Comment 6 Ovidiu D. Niţan 2013-05-02 20:57:57 UTC
As a workaround, setting Location as "Show a place:" and choosing "Desktop" instead of using "Show the Desktop folder" seems to fix this issue http://i.imgur.com/6HpAPTn.png
Comment 7 Sergey Zolotarev 2013-06-03 18:15:38 UTC
Same in KDE 4.10.3
Comment 8 Ezio Vergine 2013-08-12 12:14:41 UTC
Same problem here, kde 4.10.5
Comment 9 Mahendra Tallur 2013-08-18 07:24:53 UTC
Hi ! I would like to confirm this bug still occurs in 4.11.0.

Also, the funny thing is that :

- If I D&D a file from Ark to the aforementioned Folder View (containing the Desktop), if that file was already present in the Desktop folder, Ark asks me if I want to overwrite it. Even if the file is actually copied to my homedir ! (and the file was not present before in the home dir)
Comment 10 Eike Hein 2013-12-09 15:16:15 UTC
This still happens in Ark from KDE 4.12 RC. It seems Ark doesn't understand the "desktop:/" URL that Folder View passed it via D-Bus. Why isn't anyone fixing this, is Ark unmaintained?
Comment 11 Ovidiu D. Niţan 2014-01-10 21:50:52 UTC
I think Ark should first  extract the archive content in a temporary directory and after then, using KIO's CopyJob to move the extracted files into the destination directory. This should fix this bug and also enable unarchiving to remote locations, such is ftp://.

I tried to fix this, but unfortunately my lack of experience with Qt failed my attempt.
Comment 12 Ovidiu D. Niţan 2014-01-10 21:53:57 UTC
(In reply to comment #11)
> I think Ark should first  extract the archive content in a temporary
> directory and after then, using KIO's CopyJob to move the extracted files
> into the destination directory. This should fix this bug and also enable
> unarchiving to remote locations, such is ftp://.
> 
> I tried to fix this, but unfortunately my lack of experience with Qt failed
> my attempt.

As a sidenote, this is how WinRar works on Windows. It always extracts the archive contents in a temporary directory and after it moves the file to the destination. I don't know if it's the best approach, but seems a good way of handling archive extraction for Ark, too.
Comment 13 Ignat Semenov 2014-01-11 08:24:15 UTC
The problem most likely is either in the desktop:/ kioslave or in the interaction between the latter and Ark. I'm saying this based on the fact that "Show place -> Desktop" and "Show folder -> ~/Desktop" both result in using the file:/ kioslave, whereas "Show Desktop" results in the desktop:/ kioslave being used.
Comment 14 Ovidiu D. Niţan 2014-01-11 09:44:44 UTC
(In reply to comment #13)
> The problem most likely is either in the desktop:/ kioslave or in the
> interaction between the latter and Ark. I'm saying this based on the fact
> that "Show place -> Desktop" and "Show folder -> ~/Desktop" both result in
> using the file:/ kioslave, whereas "Show Desktop" results in the desktop:/
> kioslave being used.

No, the issue isn't in the desktop:/ kioslave. Try to extract a file by dropping it on a ftp:// location (in Dolphin) and you'll get the same result.

When you extract a file, Ark change the current working directory to the destination of the extracted file. This is done using a function provided by the Qt framework, but because Qt doesn't support desktop:// or other KDE-specific kioslaves (as this is a KDE feature) the function fails and changes to the homedir instead. So the desktop:/ kioslave is OK, the bug is in Ark which tells Qt to change the directory to a KDE location.
Comment 15 Mahendra Tallur 2014-12-17 23:23:45 UTC
Hi ! I'm sorry to say this bug still occurs in KDE 4.14.2. 

I know this is not what the KDE devs usually do, but in this case, couldn't we make a silly workaround in the code to prevent it ? Most people won't understand why they cannot D&D fropm Ark onto the desktop and this is unfortunate as KDE 4 is at a really mature & final state :)

Best regards !
Comment 16 Mahendra Tallur 2014-12-17 23:47:56 UTC
(well, I mean, using Ark 2.19 and KDE platform 4.14.2, I'm not used to the new naming conventions)
Comment 17 Elvis Angelaccio 2015-11-20 16:02:57 UTC
Update: on Plasma 5, Ark does not even extract to $HOME. Nothing happens at all when drag-and-dropping to the Desktop (or Desktop Folder).
Comment 18 Ezio Vergine 2015-11-20 16:16:17 UTC
Same problem as reported into previous comment.
Kde frameworks 5.5
Comment 19 Eike Hein 2015-12-03 18:12:35 UTC
Git commit fa467314a39d596ab7bd785ced637f599c4055ba by Eike Hein.
Committed on 03/12/2015 at 18:11.
Pushed by hein into branch 'Applications/15.12'.

Try to handle URLs and resolve to local path in D-Bus extraction service.

REVIEW:126233

M  +20   -5    part/part.cpp

http://commits.kde.org/ark/fa467314a39d596ab7bd785ced637f599c4055ba
Comment 20 Mahendra Tallur 2015-12-04 08:07:58 UTC
Thanks a lot for the fix !