Bug 204323 - Ark not kio-slave capable
Summary: Ark not kio-slave capable
Status: CONFIRMED
Alias: None
Product: ark
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: HI normal
Target Milestone: ---
Assignee: Elvis Angelaccio
URL:
Keywords:
: 167730 229185 240716 272282 291437 320820 332157 397741 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-18 20:51 UTC by Marcel Partap
Modified: 2024-07-09 18:52 UTC (History)
22 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcel Partap 2009-08-18 20:51:41 UTC
Version:           2.14 (using 4.3.64 (KDE 4.3.64 (KDE 4.4 >= 20090812)), Gentoo)
Compiler:          x86_64-pc-linux-gnu-gcc
OS:                Linux (x86_64) release 2.6.31-rc5-00513-ga3620f7-dirty

Dragging a file out of an archive into a remote directory results in.... the file ending up in my home directory (with stored sub path). Huh?
Comment 1 Marcel Partap 2009-08-18 20:52:35 UTC
btw i tagged this bug because it LOOKS like it is successfull, i.e. the cursor changes to a plus and something happens. But the result is not what was intended.
Comment 2 FiNeX 2009-09-26 21:36:37 UTC
*** Bug 208384 has been marked as a duplicate of this bug. ***
Comment 3 Raphael Kubo da Costa 2010-01-01 00:21:19 UTC
*** Bug 167730 has been marked as a duplicate of this bug. ***
Comment 4 Martin Koller 2010-02-12 11:37:14 UTC
I'm not sure if bug 208384 is really a duplicate since this talks about remote-KIO but the problem with creating the subdirs also happens with a locally opened zip file in ark
Comment 5 Raphael Kubo da Costa 2010-03-03 04:20:56 UTC
*** Bug 229185 has been marked as a duplicate of this bug. ***
Comment 6 Raphael Kubo da Costa 2010-03-03 04:24:58 UTC
Martin, you're right; I've reopened bug 208384.
Comment 7 Raphael Kubo da Costa 2010-12-08 02:19:06 UTC
Changing the default assignee in the currently open Ark bug reports to me.
Comment 8 Raphael Kubo da Costa 2011-05-03 03:39:53 UTC
*** Bug 272282 has been marked as a duplicate of this bug. ***
Comment 9 Raphael Kubo da Costa 2012-01-13 15:15:31 UTC
*** Bug 240716 has been marked as a duplicate of this bug. ***
Comment 10 Raphael Kubo da Costa 2012-01-13 15:16:07 UTC
*** Bug 291437 has been marked as a duplicate of this bug. ***
Comment 11 Mahendra Tallur 2012-02-24 07:10:50 UTC
Same problem here, in 4.8.0, when extracting a file by D&D to the Plasma desktop, if the desktop is in "Folder View" mode (that is to say, if the whole desktop is set to display a single directory).

However it works when D&D'ing to a "Folder view" widget.

The extraction is successful, as, If I do the operation again, Ark asks me if I want to overwrite the file. For some strange reason, the extracted file appears in my "Documents" folder and my "Documents/Articles" folder, the latter being the path of yet another Folder View on a different activity...
Comment 12 Mahendra Tallur 2012-02-24 19:11:33 UTC
One additional remark : when the desktop is entirely in Folder View mode, if the specified location is "Display the desktop folder", the bug occurs.

However, if you specify "display the place" -> "desktop" it doesn't occur.
Comment 13 Raphael Kubo da Costa 2012-02-26 22:35:34 UTC
(In reply to comment #11)
> Same problem here, in 4.8.0, when extracting a file by D&D to the Plasma
> desktop, if the desktop is in "Folder View" mode (that is to say, if the whole
> desktop is set to display a single directory).
> 
> However it works when D&D'ing to a "Folder view" widget.
> 
> The extraction is successful, as, If I do the operation again, Ark asks me if I
> want to overwrite the file. For some strange reason, the extracted file appears
> in my "Documents" folder and my "Documents/Articles" folder, the latter being
> the path of yet another Folder View on a different activity...

This doesn't really look like the problem described in this bug report. Could you open a separate report for us to track it?
Comment 14 Mahendra Tallur 2012-02-27 07:32:55 UTC
Raphael : ah ! I thought it might be related (desktop:// path ?). 

As advised, I created this bug report : https://bugs.kde.org/show_bug.cgi?id=294904

Thanks for your reply !
Comment 15 Raphael Kubo da Costa 2013-06-06 14:27:50 UTC
*** Bug 320820 has been marked as a duplicate of this bug. ***
Comment 16 Raphael Kubo da Costa 2014-03-16 13:36:17 UTC
*** Bug 332157 has been marked as a duplicate of this bug. ***
Comment 17 Elvis Angelaccio 2015-12-08 22:04:30 UTC
Git commit 4f7a4572d74d7e2d7fa98fd1039458b0f13f6585 by Elvis Angelaccio.
Committed on 08/12/2015 at 22:00.
Pushed by elvisangelaccio into branch 'master'.

Prevent drop events to non-local destinations

We already prevent users from extracting to a non-local destination, when they
use a KFileWidget. The same should be done when they drag-and-drop to a
non-local destination in e.g. Dolphin.

Differential Revision: D565

M  +10   -2    part/part.cpp

http://commits.kde.org/ark/4f7a4572d74d7e2d7fa98fd1039458b0f13f6585
Comment 18 Elvis Angelaccio 2018-08-26 14:11:42 UTC
*** Bug 397741 has been marked as a duplicate of this bug. ***
Comment 19 Hirad 2022-07-23 14:44:54 UTC
(In reply to Elvis Angelaccio from comment #17)
> We already prevent users from extracting to a non-local destination

And why is that? This limitation makes no sense and only cause headache when you have to extract archives to remote directories.
Comment 20 Elvis Angelaccio 2022-09-19 22:28:17 UTC
(In reply to Hirad from comment #19)
> (In reply to Elvis Angelaccio from comment #17)
> > We already prevent users from extracting to a non-local destination
> 
> And why is that? This limitation makes no sense and only cause headache when
> you have to extract archives to remote directories.

Because no one has wrote the code to implement this feature yet.