Version: 2.13 (using 4.3.1 (KDE 4.3.1) "release 161", KDE:KDE4:Factory:Desktop / openSUSE_11.1) Compiler: gcc OS: Linux (i686) release 2.6.31-rc5-8-pae I've tried to extract a file by dragging it to dolphin. To my surprise the folder structure (of the archive) was re-created. Instead, I only expect the single file to be extracted in the target folder. Example use case: - download jquery.mousewheel.3.0.2.zip - open it in ark - drag the relevant JS file to your project.
*** This bug has been marked as a duplicate of bug 204323 ***
Reopening, this actually isn't related to kioslaves.
SVN commit 1124377 by rkcosta: Do not preserve paths when extracting via drag'n'drop. CCBUG: 208384 M +1 -2 part.cpp M +1 -1 part.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1124377
SVN commit 1124379 by rkcosta: Backport r1124377. Do not preserve paths when extracting via drag'n'drop. BUG: 208384 M +1 -2 part.cpp M +1 -1 part.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1124379
please reopen. this bug is only partially fixed. dragging files now works as expected, but when dragging a folder from ark to dolphin, it should recreate the partial folder structure beginning with the dragged folder. so if my archive contains: a/b/c.txt and i drag the folder b into my home directory, i should have: /home/b/ /home/b/c.txt but currently i get: /home/c.txt
This seems to be true only to zip files, which are extracted via the 'unzip' utility. It has no way of specifying which directory to start extracting from. A possible workaround in this case would be extracting with the full path to a temporary directory and moving the desired parts to the final directory.
SVN commit 1129641 by rkcosta: Revert 1124377. All plugins but clizip support RootNode, and PreservePaths is needed in order for dragging and dropping a directory to create the proper structure. CCBUG: 208384 M +1 -0 part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1129641
SVN commit 1129642 by rkcosta: Backport 1129641. Revert 1124379. All plugins but clizip support RootNode, and PreservePaths is needed in order for dragging and dropping a directory to create the proper structure. CCBUG: 208384 M +1 -0 part.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1129642
The funny thing is that it works properly when dragging to Folder View Plasma widget. Actually it looks like it triggers another action since it opens a context menu after dropping, just like with regular files from the filesystem.
Changing the default assignee in the currently open Ark bug reports to me.
I have the same behaviour, when I have the following directory structure inside zip archive: dir dir/dir.txt dir/a dir/a/a.txt Dragging and dropping the 'a' element into /tmp/test/ results in: test/dir test/dir/a test/dir/a/a.txt I would expect it to be: test/a test/a/a.txt
On the other hand, when that directory structure is inside RAR archive I end up having: test/dir test/dir/a test/dir/a/a test/dir/a/a/a.txt (which is also related to bug 272281 - but maybe this helps too...)
Created attachment 59557 [details] An archive that demonstrates the problem
Created attachment 59558 [details] An archive that demonstrates the problem
I have this problem too. And here, drag n drop with multiple files do not working here. It extract only a single file.
I have the same problem with multible archive formats: - it is possible to drag&drop ONE file from the archive to dolphin ( in my case) - if i try to d&d multiple files (2 or mor or just a coice of files) id just copies one a fix of this issue wold be great help to me! thanks all that are working so hard on the fix!
(In reply to comment #16) > - if i try to d&d multiple files (2 or mor or just a coice of files) id just > copies one This is actually a different issue, please see bug 187152.
Changing the title of the bug from "Dragging a file to dolphin to extract, will create a folder structure" to "Extracting selected files will always create the whole directory structure". This better reflects the reality and shows it is a more general problem not restricted to dragging and dropping. While working on bug 187152 today, I came to think about this report again. Let us consider the example described in comment #11 again: > dir > dir/dir.txt > dir/a > dir/a/a.txt If that directory structure was present in the filesystem and one used a file manager such as Dolphin to drag or copy "/tmp/dir/a" to "/tmp/other-dir", the resulting structure would be "/tmp/other-dir/a", not "/tmp/other-dir/dir/a/" or "/tmp/other-dir/tmp/dir/a". From the comments in this report, it looks like people expect Ark to act the same way; that is, selecting "a" in the tree structure and extracting (or dragging it) to "/tmp/other-dir" would result in "/tmp/other-dir/a", not "/tmp/other-dir/dir/a/". The latter is what both dragging'n'dropping _and_ regular extraction create. Replicating the expected behavior with compressed archives is made more difficult due to the archive management programs themselves (unzip, unrar, lha and 7z), as they are usually not capable of easily handling this. As I mentioned in comment #6, a possible workaround involves extracting the desired files into a temporary location and later moving them (I'd like to avoid this because the temporary directory might be in another partition with little disk space, for example), or separating the selected files by common parent and extracting them separately. Other ideas welcome :)
(In reply to comment #18) > As I mentioned in comment #6, a possible workaround involves extracting the > desired files into a temporary location and later moving them (I'd like to > avoid this because the temporary directory might be in another partition with > little disk space, for example), or separating the selected files by common > parent and extracting them separately. Other ideas welcome :) How about creating the directory structure manually, not through the archiving tool, and extracting individual files to appropriate directories, while making the archiving tool skip the directories altogether? I haven't check all the tools, but at least the main ones allow to do that. All of the following extract 'file.txt' into the current directory: unzip -j arch.zip dir/a/b/c/file.txt unrar e arch.rar dir/a/b/c/file.txt 7z e arch.7z dir/a/b/c/file.txt For tar, I couldn't find an option that would prevent it from recreating the whole directory structure, but -O can be used and the output redirected to a specific file (at the cost of loosing all the attributes): tar -O -xzf arch.tar.gz dir/a/b/c/file.txt > file.txt
(In reply to comment #19) > How about creating the directory structure manually, not through the archiving > tool, > and extracting individual files to appropriate directories, > while making the archiving tool skip the directories altogether? This is a variation on the second idea I mentioned. The potential downside is that we may end up creating a lot of jobs in case the selected files all live in separate directories with no common ancestors. Unfortunately, this may be the only way to go...
How about extract in a tmp dir in the target location which then gets deleted? ie. extracting dir/a -> /tmp/other-dir would: extract dir/a -> /tmp/other-dir/.ark_temp/dir/a mv /tmp/other-dir/.ark_temp/dir/a -> /tmp/other-dir/a rm -rf /tmp/other-dir/.ark_temp That way it works independently of what each tool supports while the different filesystem problem is also solved. Just make sure '.ark_temp' gets removed on a failed extraction and in case it exists (for whatever reason), work on '.ark_temp(2)' etc.
(In reply to comment #21) > How about extract in a tmp dir in the target location which then gets deleted? > ie. > extracting dir/a -> /tmp/other-dir would: > extract dir/a -> /tmp/other-dir/.ark_temp/dir/a > mv /tmp/other-dir/.ark_temp/dir/a -> > /tmp/other-dir/a > rm -rf /tmp/other-dir/.ark_temp > > That way it works independently of what each tool supports while the different > filesystem problem is also solved. > > Just make sure '.ark_temp' gets removed on a failed extraction and in case it > exists (for whatever reason), work on '.ark_temp(2)' etc. Hmm, that might be a good idea. The cumbersome side is handling filenames which already exist (Ark would need to do that after the extraction has finished) and moving things around, but I think this is the best proposal so far :)
*** Bug 290034 has been marked as a duplicate of this bug. ***
This bug is 2 years old! And this is a very important feature broken...
I have build ark from master (SHA 8a3e5d96d295b78734845bd3358b55c0534da5a1) that icludes your latest changes and this bug continues being valid...
(In reply to comment #25) > I have build ark from master (SHA 8a3e5d96d295b78734845bd3358b55c0534da5a1) > that icludes your latest changes and this bug continues being valid... That's why the bug is still open :)
It's a annoying problem! please fix it!
Is a fix in the works??
*** Bug 307017 has been marked as a duplicate of this bug. ***
Please fix this... is a very annoying bug, especially when other archive managers like GNOME's file-roller work very well... :P
Is there any known workaround for this bug? AFAIK it is not possible to use File-Roller or Xarchiver since drag&drop XDS [1] property is not supported by KDE file managers (Dolphin). I tried few other archivers, but to no avail either. One method to be used with some supported archive types would be to open the archive within Dolphin itself, but that seems pretty buggy, too. (Works for some ZIP files, not for others. Similar like described here [2] and here [3].) Krusader works fine, but it is too much complicated for a simple mouse driven use style... [1] http://freedesktop.org/wiki/Specifications/XDS?action=show&redirect=Standards%2FXDS [2] https://bugs.kde.org/show_bug.cgi?id=216672 [3] http://forum.kde.org/viewtopic.php?f=224&t=107415
I've tried the latest Kubuntu 13.04 daily build and it seems to be fixed. Can anyone else confirm as well? :-)
(In reply to comment #32) > I've tried the latest Kubuntu 13.04 daily build and it seems to be fixed. Arch linux, KDE 4.10.00, Ark 2.19. With ZIP or 7ZIP files, it is still buggy (full path is extracted via drag&drop). With TAR.GZ files, things work as expected (though it should ask whether the files/folders should be extracted with full path or not). To me, it seems still buggy.
*** Bug 319911 has been marked as a duplicate of this bug. ***
Created attachment 79952 [details] Proposed patch for CLI apps like unzip
The patch I just submited makes cli apps that do not support "rootNode" extraction (the problem described here) makes this cli apps work on a tmp directory called "._ark_extract". I just realized that it is not safe if you extract many zips simultaneously to the same destination directory. I will post another patch shortly that adds a random uuid to the directory.
Created attachment 79954 [details] Extract to temporary subdirectory safe for simultaneous extracts Previous patch with the addition of random uuid to the temporary directory
Thank you for the patch. Please note, though, that patches should be submitted via ReviewBoard instead of Bugzilla. See http://techbase.kde.org/Contribute/Send_Patches#Reviewboard for more information.
Thank you. Patch submited: https://git.reviewboard.kde.org/r/110516/
The patch has not been accepted because it overwrites without prompt. This is caused because I use QFile->rename instead of the corresponding KIO call. I've been trying to create a move job for this patch but I don't seem to be able to make it work. The notifier widget always shows that I create a blank job and no file gets moved at all. I've been trying to find documentation and examples of KIO::move() with no luck. I found the API documentation, but it seems to be focused on developers who already understand KIO Jobs. I would really appreciate if someone could give me a link with KIO Jobs or KIO::move documentation and/or examples. This is what I tried: http://pastebin.com/2ce3aRes
*** Bug 333670 has been marked as a duplicate of this bug. ***
the bug is still here with ark-4.14.3
Git commit 7c025dd5765c41957787493786248157f29b4e13 by Ragnar Thomsen. Committed on 21/09/2015 at 19:25. Pushed by rthomsen into branch 'Applications/15.08'. Fix drag'n'drop extraction with CLI-plugins This fixes drag'n'drop extraction of selected entries from Ark to e.g. Dolphin for archives handled by CLI-plugins. Previously, the entries would be extracted with full path, which is not what the user expects and not how the libarchive-plugin handles tar-based archives. This was due to CLI-plugins not supporting individual root nodes (i.e. removing a part of the path from entry to be extracted). This is now circumvented by extracting to a QTemporaryDir, removing the root node from the path, and finally moving the files to their final destination. The moving to final destination is done in a new member function in CliInterface (moveToFinalDest). This function checks if the destination file exists and prompts the user for action if that is the case. The finished signal() is now emitted from copyFiles()/addFiles()/ deleteFiles()/list(), instead of from processFinished(). FIXED-IN: 15.08.2 REVIEW: 125293 M +108 -9 kerfuffle/cliinterface.cpp M +3 -0 kerfuffle/cliinterface.h http://commits.kde.org/ark/7c025dd5765c41957787493786248157f29b4e13
*** Bug 359049 has been marked as a duplicate of this bug. ***
*** Bug 359565 has been marked as a duplicate of this bug. ***