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
operation.

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.

This effectively breaks drag and drop for large files so
I'm setting this as targeted for 2.2.0

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.

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
release.

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?

Major, but not a showstopper for any GNOME release

And why not extract the archive to tmp when you open it, then remove
it from tmp when closing ?

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.

*** Bug 121938 has been marked as a duplicate of this bug. ***

*** Bug 122209 has been marked as a duplicate of this bug. ***

*** Bug 137661 has been marked as a duplicate of this bug. ***

*** Bug 137756 has been marked as a duplicate of this bug. ***

*** Bug 149679 has been marked as a duplicate of this bug. ***

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
window.c):

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

It worked for me and doesn't look like a leak.

In my current GNOME 2.8 environment I cannot DnD-extract to nautilus windows at all.

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.

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

*** Bug 116997 has been marked as a duplicate of this bug. ***

My girlfriend just ran into this. Blah. Paolo? Have you looked at this?

I just don't know how to fix this, Mark Finlay on comment #4 explained the
problem quite well.  I need a tip.

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

Has there been any movement/anyoen come up with a solution for this?
This is a rather killer bug.

If GnomeVFS worked correctly, I suppose we could just pass URIs like

file:///myfooarchive.tar.gz#gzip://myfooarchive.tar#tar://Folder1
file:///myfooarchive.tar.gz#gzip://myfooarchive.tar#tar://File2

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:///
segfaults.
CCing Christian Kellner. Any ideas?

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 :)

This is a duplicate of bug 97609

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.
Ciao,
  robepisc

*** Bug 327548 has been marked as a duplicate of this bug. ***

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...

*bump*

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?

Cheers.

*** Bug 97609 has been marked as a duplicate of this bug. ***

*** Bug 338152 has been marked as a duplicate of this bug. ***

And it would be nice to have this already fixed for 2.14 if possible as this is a GREAT usuability problem.

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.

*** Bug 343707 has been marked as a duplicate of this bug. ***

FROM https://launchpad.net/products/fileroller/+bug/13199 

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!

... 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.

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.

*** Bug 344716 has been marked as a duplicate of this bug. ***

Still doesnt work in Ubuntu Dapper. Gnome 2.14.1
Shouldnt this have been fixed 3 yrs ago when it was reported?

Created attachment 67374 [details] [review]
gtk-2.9.2-dnd.patch

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.

Created attachment 67375 [details]
Protocol docs

Documentation of Xdnd protocol extension.

*** Bug 345523 has been marked as a duplicate of this bug. ***

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 : http://bugzilla.gnome.org/show_bug.cgi?id=345634

You may want to add your patch there as it is gtk+ related.

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.

Can anyone confirm this in 2.16? I seem to be getting the same behavior.. Perhaps the version needs to be updated.

file-roller extracts in the background in xfce 4.4rc1 + thunar. Works wonderfully.  Pity about gnome tho. Still not closed? :(

@Brandon Williams: I can confirm here

I can confirm that this bug is still present in File Roller 2.16.0
Please update the version.

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.

*** Bug 385125 has been marked as a duplicate of this bug. ***

now this bug depends on Nautilus to add XDS support (bug #171655).

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. 

I think DnD has been disabled in 2.18, because I saw it didn't work in Nautilus either

Paolo, do you have the CVS changes (or a patch) that made this work, so we can try with 2.18.x versions?

I tried current svn trunk with thunar and it seems to work without problems.

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.

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?

*** Bug 453021 has been marked as a duplicate of this bug. ***

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?

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.

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 ?

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

*** Bug 413070 has been marked as a duplicate of this bug. ***

Nautilus has XDS support now, closing as fixed...