After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 102501 - Drag-and-drop extract operation should run instantly in background
Drag-and-drop extract operation should run instantly in background
Product: file-roller
Classification: Applications
Component: general
Other other
: High major
: ---
Assigned To: Paolo Bacchilega
: 97609 116997 121938 122209 137661 137756 149679 327548 338152 343707 344716 345523 385125 413070 453021 (view as bug list)
Depends on: 171655
Reported: 2003-01-04 16:00 UTC by David Breakey
Modified: 2008-12-10 02:12 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10

gtk-2.9.2-dnd.patch (49.84 KB, patch)
2006-06-15 04:18 UTC, Ed Catmur
none Details | Review
Protocol docs (7.94 KB, text/html)
2006-06-15 04:19 UTC, Ed Catmur

Description David Breakey 2003-01-04 15:59:49 UTC
Package: file-roller
Severity: enhancement
Version: GNOME2.1.5 2.1.4
os_details: MandrakeSoft
Synopsis: Drag-and-drop operation needs to be faster
Bugzilla-Product: file-roller
Bugzilla-Component: general
Description of Problem:
Copying files via drag-and-drop is unacceptably slow, as the application
extracts all the files before actually triggering the operation. On
large archives, especially on slower machines, this results in a severe
delay before the file manager (Nautilus) recognizes the request.

Steps to reproduce the problem:
1. Obtain an archive file of significant (decompressed) size, esp. one
containing a folder structure.
2. Open that archive in file roller.
3. Click and drag the top-level folder to a Nautilus file window.

Actual Results:
File roller reports 'extracting files' in the status bar before the operation is
recognized by Nautilus. In the meantime, I have to continue holding down
the mouse button until file roller has finished extracting; if I don't, Nautilus
does not appear to recognize the request, but file roller continues to process
the extraction.

Expected Results:
The operation should be recognized by Nautilus *before* starting the
file extraction; then file roller should put up a dialog indicating what
it is doing.

How often does this happen?
Every time.

Additional Information:

------- Bug moved to this database by 2003-01-04 10:59 -------

Reassigning to the default owner of the component,

Comment 1 Mark Finlay 2003-01-12 17:06:30 UTC
I think that the problem is that the extract operation is triggered 
on mouse-down instead of on mouse-up when doing the drag and drop

I'm fairly sure that this was not an issue with the 2.0.x series
of file-roller. This is a major usibility regression and should
be fixed ASAP.
Comment 2 Mark Finlay 2003-01-12 17:54:41 UTC
This effectively breaks drag and drop for large files so
I'm setting this as targeted for 2.2.0
Comment 3 kz 2003-01-17 17:12:11 UTC
when I've said to the author for the first release of file-roller on
gnome 1 age,
he told: it's mattter of dnd signal system. that hard to find solution.
it's not a bug, but a feature under heavy constraint.

if someone know how to solve, it'll be great.
Comment 4 Mark Finlay 2003-01-27 20:05:55 UTC
I looked into the file roller drag and drop code and here is 
a simplified description of how it works:

When you start a drag and drop operation it extracts the selected files
into a subdir in /tmp. When you release the mouse button it passes the 
location of the files in /tmp to gtk or libeggdnd or whatever the 
relavent code is and those files are copied to the directory you 
specified in your dnd.

I tried changing the code around so that the extraction takes place
after you release the mouse button instead of before but this does not
work as the file needs to already exist in the filesystem before the

Would it be possible to capture the directory that the dnd operation
drags too and extract the file directly to there instead of extracting
to /tmp first? 

Or maybe we could tweak the dnd code so that it waits for the extract 
to happen before it copies the file?
Comment 5 Andrew Sobala 2003-03-13 21:06:09 UTC
Major, but not a showstopper for any GNOME release
Comment 6 Julien Olivier 2003-10-21 09:22:45 UTC
And why not extract the archive to tmp when you open it, then remove
it from tmp when closing ?
Comment 7 Jeremy Brown 2004-07-14 05:01:09 UTC
I opened a bug under gtk/general about this and it was promptly closed.  GTK
developers claim it can be implemented with the existing DND API.

See bug #147529.
Comment 8 André Dahlqvist 2004-09-11 17:35:00 UTC
*** Bug 121938 has been marked as a duplicate of this bug. ***
Comment 9 André Dahlqvist 2004-09-11 17:37:28 UTC
*** Bug 122209 has been marked as a duplicate of this bug. ***
Comment 10 André Dahlqvist 2004-09-11 17:38:11 UTC
*** Bug 137661 has been marked as a duplicate of this bug. ***
Comment 11 André Dahlqvist 2004-09-11 17:39:04 UTC
*** Bug 137756 has been marked as a duplicate of this bug. ***
Comment 12 André Dahlqvist 2004-09-11 17:39:54 UTC
*** Bug 149679 has been marked as a duplicate of this bug. ***
Comment 13 Yury Sulsky 2004-09-13 03:08:10 UTC
I posted a duplicate bug a while back, in which I pointed out that the fix seems
pretty obvious--comment out these lines in file_list_drag_end (lines 2381-2 in

if (window->extracting_dragged_files) 
		window->extracting_dragged_files_interrupted = TRUE;

It worked for me and doesn't look like a leak.
Comment 14 Reinout van Schouwen 2004-10-25 12:48:12 UTC
In my current GNOME 2.8 environment I cannot DnD-extract to nautilus windows at all.
Comment 15 Kjartan Maraas 2005-01-06 14:11:17 UTC
It works here when I open a tarball in file-roller and drag a folder in the
tarball to a nautilus window. Not sure how it works with large tarballs though.
Comment 16 Sebastien Bacher 2005-01-06 14:41:21 UTC
I've just tried with a 100M tarball here, I still get the issue, I have to wait
to time with the button pressed to get it working correctly. Updating the Version
Comment 17 Sebastien Bacher 2005-01-13 13:27:01 UTC
*** Bug 116997 has been marked as a duplicate of this bug. ***
Comment 18 Luis Villa 2005-01-30 18:09:35 UTC
My girlfriend just ran into this. Blah. Paolo? Have you looked at this?
Comment 19 Paolo Bacchilega 2005-02-01 13:34:58 UTC
I just don't know how to fix this, Mark Finlay on comment #4 explained the
problem quite well.  I need a tip.
Comment 20 Chris Jones 2005-04-10 12:51:27 UTC
If I understand correctly the problem is that the gtk DnD only submits data one
way, to the application that receives the drop.

I have no code to submit but this seems to be a solution:
  1.On drop link target directory with /tmp/unzip_directory

  2.Unzip into files/directory into /tmp/unzip_directory

Comment 21 Trent "Lathiat" Lloyd 2005-09-01 02:03:07 UTC
Has there been any movement/anyoen come up with a solution for this?
This is a rather killer bug.
Comment 22 Christian Neumair 2005-09-08 17:47:56 UTC
If GnomeVFS worked correctly, I suppose we could just pass URIs like


and the extraction would work using the GnomeVFS machinery.

gnomevfs-info file:///foo.tar.gz#gzip:/// seems to return info about the
encapsulated tarball, but doing gnomevfs-info file:///foo.gz#gzip:///#tar:///
CCing Christian Kellner. Any ideas?
Comment 23 Christian Kellner 2005-09-08 18:00:34 UTC
Yes! Manny is totally right. URI chaining would rock so hard. DnD for
file-roller is "teh suck" atm. I am going to fix uri chaining (rewrite some of
the methods) for 2.14. At least that's the plan :) We also need a zip method and
maybe some more. If anybody wanna help me with that raise your hand :)
Comment 24 Keith Lea 2005-10-19 21:34:01 UTC
This is a duplicate of bug 97609
Comment 25 Roberto Piscitello 2005-11-11 01:32:47 UTC
I don't know any technical detail about DND, so maybe what I say has no meaning
at all, but here's my idea.
When the user starts dragging (or when the archive is opened), a tree of _empty_
files (but with the same names and permissions of the ones the user is dragging
from the archive) is created in /tmp.
When the user releases his mouse button, the empty files are copied to the
destination and then File Roller starts extracting the real files, "filling" the
empy ones and showing a nice progress bar.
This way files are extracted "in place" and DND issues (if I understood them
right from the above comments) are worked around.
I don't know if I've been clear and, again, if it has any meaning at all.
Comment 26 Paolo Bacchilega 2006-01-22 11:00:31 UTC
*** Bug 327548 has been marked as a duplicate of this bug. ***
Comment 27 Stefan Bethge 2006-03-09 15:13:21 UTC
I think it's a bad idea, to first extract to /tmp and then copy/move the files
again. All major archive tools should be able to extract directly. If it is possible to get the information from nautilus where the files are to be extracted,
then shouldn't it be possible to extract to that dir instead of /tmp upon mouse up, and that's it?
I'd say it's quite bad that this takes more than 3 years to be fixed...
Comment 28 Steven Brown 2006-04-09 00:19:57 UTC

As mentioned already, when dragging and dropping, the user should NOT be required to keep the mouse button pressed until they see the extraction to /tmp has finished.  This is a huge usability problem and has been around for years.  I do not think the extraction should start until the user has actually *dropped* the item in the destination (and the destination is valid, etc.).

If patching the existing implementation is not feasable, then maybe a rewrite of that section of code should be considered?

Comment 29 Fabio Bonelli 2006-04-12 08:33:48 UTC
*** Bug 97609 has been marked as a duplicate of this bug. ***
Comment 30 Fabio Bonelli 2006-04-12 08:33:59 UTC
*** Bug 338152 has been marked as a duplicate of this bug. ***
Comment 31 Sebastian Dröge (slomo) 2006-04-30 09:44:20 UTC
And it would be nice to have this already fixed for 2.14 if possible as this is a GREAT usuability problem.
Comment 32 Campbell Barton 2006-05-29 01:50:30 UTC
My girlfriend ran into this problem too on ubuntu, Was tryingto show how useable gnome was for installing sunbird- a tar'd binary, This realy needs to be foxed for 2.16,

Seems like there must be a workaround for this.
Comment 33 Elijah Newren 2006-06-02 19:21:58 UTC
*** Bug 343707 has been marked as a duplicate of this bug. ***
Comment 34 Kevin Lamontagne 2006-06-03 04:54:28 UTC

well, I have good news! I've just installed suse 10.1 and file-roller seems to support drag and drop well! this means that we could see which patch suse used and incorporate it in ubuntu too!
Comment 35 Kevin Lamontagne 2006-06-03 04:59:16 UTC
... And do not forget that in the case of a nautilus/file-roller crash, the target directory must not be littered with only part of the extracted files. This is what must explain the current behaviour. Please check if suse worked around this sub-issue.
Comment 36 Ed Catmur 2006-06-03 13:19:41 UTC
re comment 34: no, file-roller in suse 10.1 does not have any patches for this bug. Perhaps you were confused by file-roller caching the unpacked files.
Comment 37 Elijah Newren 2006-06-13 04:15:00 UTC
*** Bug 344716 has been marked as a duplicate of this bug. ***
Comment 38 Toma- 2006-06-13 04:34:30 UTC
Still doesnt work in Ubuntu Dapper. Gnome 2.14.1
Shouldnt this have been fixed 3 yrs ago when it was reported?
Comment 39 Ed Catmur 2006-06-15 04:18:13 UTC
Created attachment 67374 [details] [review]

Patch to gtk+ DND to allow deferral of drag data generation till after mouse is released, in a non-blocking, parallelisable fashion. Key API is GTK_TARGET_OFFER_DELAYED_TRANSFER, GTK_TARGET_REQUIRE_DELAYED_TRANSFER GtkTargetFlags and gtk_drag_update_targets(). Fully compatible with standard Xdnd (uses specific targets to initiate delayed transfer).

nautilus and file-roller patches still need writing; should be fairly trivial.
Comment 40 Ed Catmur 2006-06-15 04:19:43 UTC
Created attachment 67375 [details]
Protocol docs

Documentation of Xdnd protocol extension.
Comment 41 Christian Kirbach 2006-06-22 08:10:53 UTC
*** Bug 345523 has been marked as a duplicate of this bug. ***
Comment 42 Christian Kirbach 2006-06-22 08:32:39 UTC
still applies to file-roller 2.14

Lets fix this soon, this report has been rottening for ages.
Ed, I filed a new gtk+ bug :

You may want to add your patch there as it is gtk+ related.
Comment 43 Daniel Holbach 2006-08-02 11:52:28 UTC
Ubuntu but comment:
"well, I have good news! I've just installed suse 10.1 and file-roller seems to support drag and drop well! this means that we could see which patch suse used and incorporate it in ubuntu too!"

I tried to find the patch, but I failed.
Comment 44 Brandon Williams 2006-09-29 18:52:44 UTC
Can anyone confirm this in 2.16? I seem to be getting the same behavior.. Perhaps the version needs to be updated.
Comment 45 Toma- 2006-09-30 06:19:12 UTC
file-roller extracts in the background in xfce 4.4rc1 + thunar. Works wonderfully.  Pity about gnome tho. Still not closed? :(
Comment 46 NoWhereMan 2006-10-14 13:12:56 UTC
@Brandon Williams: I can confirm here
Comment 47 petrosyan 2006-11-23 06:10:30 UTC
I can confirm that this bug is still present in File Roller 2.16.0
Please update the version.
Comment 48 Paolo Bacchilega 2006-12-16 15:51:37 UTC
This is fixed in CVS now.  I tested it with Thunar and seems to work good.  I couldn't test it with Nautilus because it does not support the XDS protocol yet. 

Sorry for taking so long to fix this bug.
Comment 49 Paolo Bacchilega 2006-12-16 15:57:23 UTC
*** Bug 385125 has been marked as a duplicate of this bug. ***
Comment 50 Paolo Bacchilega 2006-12-18 21:37:50 UTC
now this bug depends on Nautilus to add XDS support (bug #171655).
Comment 51 Rodrigo Castro 2007-06-05 19:24:04 UTC
Paolo, thanks for your efforts, but it looks I still have this problem, even with 2.18.2. Until 2.16.2, it would start extracting at the moment I dragged to Thunar window, but I had to move the cursor out of the window and back over it to be able to drop, otherwise the window would not be selected (ie, its frame highlighted) and nothing would be saved in the directory.

With 2.18.0 and 2.18.2, though, it doesn't work at all with Thunar. I can try the same steps that worked with <= 2.16.2 and still no lucky. Do you have any idea of what may be wrong in the recent versions? 

The conclusion is that unfortunately this bug is not fixed, at least from my experience with file-roller + thunar 4.4.0 + gtk 2.10.9. 
Comment 52 NoWhereMan 2007-06-06 05:51:14 UTC
I think DnD has been disabled in 2.18, because I saw it didn't work in Nautilus either
Comment 53 Rodrigo Castro 2007-06-06 13:41:25 UTC
Paolo, do you have the CVS changes (or a patch) that made this work, so we can try with 2.18.x versions?
Comment 54 Paolo Bacchilega 2007-06-06 18:22:16 UTC
I tried current svn trunk with thunar and it seems to work without problems.
Comment 55 Rodrigo Castro 2007-06-06 18:44:46 UTC
Even svn trunk (2.19.2) does not work here with Thunar 0.8.0 (with XFCE 4.4.0). Really strange. I can't find any strategy to make it work, because there is no way to make Thunar window frame highlighted (unlike when we drag an icon from desktop). Versions up to 2.16.x didn't work very well, but I could figure out some steps to make it work (as I mentioned above). Comments and suggestions are welcome.
Comment 56 Jos Dehaes 2007-06-19 23:34:54 UTC
Current dev version of file-roller (2.19.3) works with current thunar (0.8.0) in ubuntu gutsy. Doesn't work at all with nautilus (2.19.4). Maybe this should be re-assigned to nautilus to implement the correct DND behaviour?
Comment 57 Paolo Bacchilega 2007-07-11 11:25:25 UTC
*** Bug 453021 has been marked as a duplicate of this bug. ***
Comment 58 Nick G 2007-07-17 22:22:55 UTC
Just as an idea point, but with all the advances in FUSE and Gnome-VFS is File-Roller still as relevant if the functionality can be brought about with some nice G-VFS/FUSE plugins?
Comment 59 Rodrigo Castro 2007-07-23 14:14:01 UTC
It is still not working here with 2.19.3 (svn version as of today) and Thunar 0.8.0 in Gentoo. See what I am trying that is failing:

- Open a .tar.gz with folder structure (*)
- Drag a file to Thunar window

(*) I also tried .gz and .zip files (without folder information) and I didn't have any lucky.
Comment 60 Christian Kirbach 2007-10-28 21:49:59 UTC
For my part, the Ubuntu edition of Gnome 2.20 has fixed this issue. I cannot speak for the Tunar problem, tough.

DnD works like a charm to nautilus windows. Not sure if the missing part was implemented for nautilus.

Can anyone confirm with Ubtuntu 7.10 ?
Comment 61 Benoît Dejean 2007-10-28 22:08:45 UTC
The situation has evolved but is not completed fixed:

Extracting a .zip works fine:
- drag&drop starts the extraction
- the progress bar is very small, but does not show any time, files count or percentage. the progress bar updates as expected.

Extracting a .tar.bz2 (like the linux kernel):
- drag&drop starts the extraction
- no progress bar,100% CPU (but i can't say who was using it)
- after 30s, UI freezes, still no progress bar. CPU usage is 100% file-roller.
- after 3 minutes, UI unfreezes, progress bar is full, tar+bzip2 have been spawn and are extracting.
- the progress bar disappears meaning that the extract has finished
Comment 62 Karl Lattimer 2007-12-29 16:25:54 UTC
*** Bug 413070 has been marked as a duplicate of this bug. ***
Comment 63 Paolo Bacchilega 2007-12-30 10:29:51 UTC
Nautilus has XDS support now, closing as fixed...