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?
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.
*** Bug 208384 has been marked as a duplicate of this bug. ***
*** Bug 167730 has been marked as a duplicate of this bug. ***
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
*** Bug 229185 has been marked as a duplicate of this bug. ***
Martin, you're right; I've reopened bug 208384.
Changing the default assignee in the currently open Ark bug reports to me.
*** Bug 272282 has been marked as a duplicate of this bug. ***
*** Bug 240716 has been marked as a duplicate of this bug. ***
*** Bug 291437 has been marked as a duplicate of this bug. ***
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...
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.
(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?
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 !
*** Bug 320820 has been marked as a duplicate of this bug. ***
*** Bug 332157 has been marked as a duplicate of this bug. ***
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
*** Bug 397741 has been marked as a duplicate of this bug. ***
(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.
(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.