Bug 208384 - Extracting selected files will always create the whole directory structure
Summary: Extracting selected files will always create the whole directory structure
Status: RESOLVED FIXED
Alias: None
Product: ark
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal with 133 votes (vote)
Target Milestone: ---
Assignee: Ragnar Thomsen
URL:
Keywords:
: 290034 307017 319911 333670 359049 359565 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-09-24 14:02 UTC by Diederik van der Boor
Modified: 2016-02-19 11:49 UTC (History)
25 users (show)

See Also:
Latest Commit:
Version Fixed In: 15.08.2


Attachments
An archive that demonstrates the problem (604 bytes, application/octet-stream)
2011-05-02 23:29 UTC, Jakub Schmidtke
Details
An archive that demonstrates the problem (212 bytes, application/octet-stream)
2011-05-02 23:29 UTC, Jakub Schmidtke
Details
Proposed patch for CLI apps like unzip (2.84 KB, patch)
2013-05-18 17:36 UTC, Francesc Ortiz
Details
Extract to temporary subdirectory safe for simultaneous extracts (5.81 KB, patch)
2013-05-18 17:50 UTC, Francesc Ortiz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Diederik van der Boor 2009-09-24 14:02:19 UTC
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.
Comment 1 FiNeX 2009-09-26 21:36:37 UTC

*** This bug has been marked as a duplicate of bug 204323 ***
Comment 2 Raphael Kubo da Costa 2010-03-03 04:24:07 UTC
Reopening, this actually isn't related to kioslaves.
Comment 3 Raphael Kubo da Costa 2010-05-09 03:25:05 UTC
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
Comment 4 Raphael Kubo da Costa 2010-05-09 03:33:05 UTC
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
Comment 5 Erwin Mascher 2010-05-20 12:03:15 UTC
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
Comment 6 Raphael Kubo da Costa 2010-05-23 06:16:56 UTC
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.
Comment 7 Raphael Kubo da Costa 2010-05-23 07:35:42 UTC
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
Comment 8 Raphael Kubo da Costa 2010-05-23 07:37:12 UTC
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
Comment 9 Bartosz Brachaczek 2010-08-12 22:09:49 UTC
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.
Comment 10 Raphael Kubo da Costa 2010-12-08 02:19:11 UTC
Changing the default assignee in the currently open Ark bug reports to me.
Comment 11 Jakub Schmidtke 2011-05-02 23:27:06 UTC
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
Comment 12 Jakub Schmidtke 2011-05-02 23:28:42 UTC
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...)
Comment 13 Jakub Schmidtke 2011-05-02 23:29:22 UTC
Created attachment 59557 [details]
An archive that demonstrates the problem
Comment 14 Jakub Schmidtke 2011-05-02 23:29:34 UTC
Created attachment 59558 [details]
An archive that demonstrates the problem
Comment 15 Alessandro Nakamuta 2011-05-22 20:11:24 UTC
I have this problem too. And here, drag n drop with multiple files do not working here. It extract only a single file.
Comment 16 christian kießling 2011-10-04 13:32:24 UTC
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!
Comment 17 Raphael Kubo da Costa 2011-10-04 16:08:02 UTC
(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.
Comment 18 Raphael Kubo da Costa 2011-12-05 03:37:20 UTC
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 :)
Comment 19 Jakub Schmidtke 2011-12-05 05:40:13 UTC
(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
Comment 20 Raphael Kubo da Costa 2011-12-05 12:44:39 UTC
(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...
Comment 21 Leonidas Arvanitis 2011-12-05 13:47:21 UTC
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.
Comment 22 Raphael Kubo da Costa 2011-12-06 15:32:34 UTC
(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 :)
Comment 23 Raphael Kubo da Costa 2011-12-28 18:14:27 UTC
*** Bug 290034 has been marked as a duplicate of this bug. ***
Comment 24 2011-12-28 18:19:34 UTC
This bug is 2 years old!
And this is a very important feature broken...
Comment 25 2011-12-29 14:50:41 UTC
I have build ark from master (SHA 8a3e5d96d295b78734845bd3358b55c0534da5a1) that icludes your latest changes and this bug continues being valid...
Comment 26 Raphael Kubo da Costa 2011-12-29 15:27:13 UTC
(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 :)
Comment 27 Daniele Scasciafratte 2012-03-25 13:34:05 UTC
It's a annoying problem!
please fix it!
Comment 28 oracle2b 2012-06-06 18:36:21 UTC
Is a fix in the works??
Comment 29 Christoph Feck 2012-09-19 09:48:12 UTC
*** Bug 307017 has been marked as a duplicate of this bug. ***
Comment 30 tesfabpel 2012-10-16 15:28:10 UTC
Please fix this... is a very annoying bug, especially when other archive managers like GNOME's file-roller work very well... :P
Comment 31 Milan Knížek 2012-12-14 09:01:09 UTC
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
Comment 32 tesfabpel 2013-02-11 10:45:46 UTC
I've tried the latest Kubuntu 13.04 daily build and it seems to be fixed.
Can anyone else confirm as well?
:-)
Comment 33 Milan Knížek 2013-02-11 17:19:29 UTC
(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.
Comment 34 Raphael Kubo da Costa 2013-05-16 15:08:50 UTC
*** Bug 319911 has been marked as a duplicate of this bug. ***
Comment 35 Francesc Ortiz 2013-05-18 17:36:01 UTC
Created attachment 79952 [details]
Proposed patch for CLI apps like unzip
Comment 36 Francesc Ortiz 2013-05-18 17:41:55 UTC
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.
Comment 37 Francesc Ortiz 2013-05-18 17:50:26 UTC
Created attachment 79954 [details]
Extract to temporary subdirectory safe for simultaneous extracts

Previous patch with the addition of random uuid to the temporary directory
Comment 38 Raphael Kubo da Costa 2013-05-18 18:49:11 UTC
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.
Comment 39 Francesc Ortiz 2013-05-18 21:29:53 UTC
Thank you. Patch submited:

https://git.reviewboard.kde.org/r/110516/
Comment 40 Francesc Ortiz 2013-06-10 08:23:56 UTC
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
Comment 41 Raphael Kubo da Costa 2014-04-21 10:25:36 UTC
*** Bug 333670 has been marked as a duplicate of this bug. ***
Comment 42 Sergey 2015-03-09 10:23:18 UTC
the bug is still here with ark-4.14.3
Comment 43 Ragnar Thomsen 2015-09-21 19:27:21 UTC
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
Comment 44 Elvis Angelaccio 2016-02-06 09:49:05 UTC
*** Bug 359049 has been marked as a duplicate of this bug. ***
Comment 45 Elvis Angelaccio 2016-02-19 11:49:27 UTC
*** Bug 359565 has been marked as a duplicate of this bug. ***