extracting doesn't work right when the location entry is displayed

Thanks for reporting this bug.

Please tell us, which Ubuntu release do you use (Dapper, Edgy)?

Feisty. It's all in the apport file.

Thank you for your bug. What type of archive do you try to unpack? Is you desktop on a different partition than the archive you are working on? Do you try to extract the archive or select the file and right click on it to extract? Is that specific to one file archives only?

I've noticed this with all archive types I tried (rar, tar.gz, tar.bz2, zip).

The archive is on the Desktop (but it happens even if it isn't). The home folder is on a different partition than the root, but this shouldn't be visible to the program, right?

The same thing happens if I click "Extract" on the toolbar or in the file's right-click menu.

It happens with any kind of archive contents.

OK, I noticed something that may give the solution:

To extract something, you are displayed a dialog named "Extract" which allows you to pick the destination of the files and some options. The dialog is a variant of the standard "Open"/"Save" dialogs of Gnome. These dialogs have on the top side a list of buttons that mirror the path of the displayed directory. In my case, this means a button for my home folder, followed by a button for the Desktop (the displayed folder) and preceded by a left-pointing arrow to go higher in the hierarchy. (There's also a "Create folder" button.)

To the left of this string of buttons, there's a button with an "edit text" icon. When clicked, this hides/displays a line of text-entry just below the buttons, labeled "Location". You can enter a relative path in that line, and navigating around using the icons below changes its contents in some weird way.

OK, the point is, the problem I reported above only shows when that line is displayed. If the line is hidden, everything works OK. (i.e., the extract button works.) If the line is displayed, it only works after rummaging a bit through the files.

I'm not sure what's wrong with it, but I believe it thinks you didn't choose a directory until you do some navigation. There must be some hidden variable there, because the line is empty when the dialog is displayed, and it doesn't work, but after walking a bit on the disk and returning to the desktop it's still empty, the whole dialog looks exactly the same as in the beginning, but now it works.

Oh, and drag-and-drop never works for me.

Confirmed, when the location entry is displayed it doesn't work correctly, I've forwarded the bug upstream: http://bugzilla.gnome.org/show_bug.cgi?id=403985

Is there a bug-report about the drag and drop completely not working with any types of files and archives? Or should I make one? I see it mentioned here, so I don't know if its related (if its the same bug or not) ..

drag and drop has bug #13199 open

bug #13199 is a different issue, for drag and drop on large archives.

I find that I can't extract any files at all using drag and drop, not even from tiny .zip archives.

I can add to archives by dragging from nautilus, but can't extract by dragging to nautilus - when I release the mouse button, the icon I was dragging flies back to the file-roller window.

did you read the new comments on the other bug?

I did read the comments on the other bug. Most of them seem to be completely off-topic there as well.

The other bug is a report about how it's not possible to extract folders using drag and drop, but the comments are talking about a different, newer bug, which disables drag and drop extraction completely.

Aren't these 2 separate bugs?

the dnd not working correctly has been fixed by using a new method, now nautilus needs to be updated. The bug can be closed and a new one opened or been recycled which is what is done currently

OK, so the headline/subject/whatever-you-call-it needs updating.

This issue is still present in Gutsy. There's a kind of a workaround.

Ignoring the drag and drop comments completely, the original bug described can be reproduced as:

1. Open a (eg) zip file in a folder, eg the file /w/zip/zipfile.zip containing a single file.

2. Optionally select the file.

3. Press extract. The extract location dialog box appears.

4. Press the extract button in this dialog box. Nothing happens.

5. Enter '.' as the extract location and press the enter key or the extract button. Fill-roller complains: "The folder could not be created. /w/zip already exists."

The workaround:

6. Along the top are buttons for 'w' and for 'zip'. Click on 'w' and then click on 'zip'. Then click extract. This time it works. It doesn' t matter if you have done step 5 or not.

The problem is a general one in GTK+'s FileChooser, which File Roller is using in the Extract dialog. The bug is already known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=402349.

@Bogdan Butnaru: good eye... this had been bothering me for a while, but I never noticed the effect of hiding the Location bar. Good to hear upstream is aware of this.

Same problem here:

if I open a file in Downloads/ and try to extract it to Downloads/ (working dir and default) - I am not able to extract the files.

If I click on Extract (Entpacken) this click will be ignored. If I select Downloads/ from my Bookmarks the Extract button works and the files are extracted to Downloads/.

Ubuntu 9.04 - AMD 64

This is still happening in karmic with libgtk 2.17.7-0ubuntu3 and file-roller 2.27.91-0ubuntu1.

And it drives me _nuts_. :)

Just marked 310543 and its 3 duplicates as duplicates of this bug, since it is the same problem, even if the exact method of reproducing varies - in all, *something* has to change about the state of the filechooser before it'll extract.
The only aberration is that comment 7 could no longer reproduce in karmic a while ago with file-roller 2.26.1, but it doesn't mention the version of this library that actually has the bug, may actually be the effect of changing some other state, and there's also the possibility of a regression.

I have had this issue throughout Hardy, Intrepid, Jaunty, and now Karmic.
To reproduce:
1. Open an archive with Archive Manager (file-roller).
2. Click the extract button.
3. In the file selection dialog, let the initially selected folder stay selected; just click extract. Nothing happens.
4a. Now, select another folder, and click extract. Files are extracted to the folder.
4b. Alternatively, I can go one folder up, then select the folder that was initially selected myself. Then extracting works.

What should happen:
3. In the file selection dialog, let the initially selected folder stay selected; just click extract. Files are extracted to the folder.

Also in my case,
if the "Location" text entry is hidden, then the bug does not occur, as upstream says.
Good to finally have a workaround.

No one seems to care...

Such things, indeed very easy to resolve and yet being around for years, annoying, play significant role in picturing Ubuntu as an ugly odd job :(

For me, it helps do change the directory and change back to the directory where I want the files extracted...

But still annoying!!!

Ubuntu 9.10
Linux ubuntu 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux

I think this might be related to https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/227731

Same thing here:

Karmic 32-bit
2.28.1-0ubuntu1

If I attempt to hit extract right away to extract to the default location (my home directory) nothing happens. Going to the parent directory and then back, however, fixes the problem.

I am not sure everbody understands the workaround, since there are so many people saying nothing happens when they click the extract button on the selection dialog.
If you click the pen to hide the Location text box, extracting will work for that system until you show it again.
The workaround, as a picture:
http://fileupl.com/thumb_show.php?i=ndohwv&n=Screenshot.png

Thank you for bringing this bug to our attention. However, a paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix. So this bug can't be addressed as part of this project.

-- This bug has been around for quite a while and no one seems to know a fix for this. [apart from the workaround of not displaying the location entry] Marking it as incomplete in papercuts _for now_ .
For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Incomplete" only in the papercuts project.

The fix in the gnome-bugs bug for this
https://bugzilla.gnome.org/show_bug.cgi?id=402349#c12
seems to work well for me.

I faced this in lucid a few days ago but today I can't reproduce this. can any one facing this please test this under lucid(updated).

This bug was fixed in the package gtk+2.0 - 2.19.7-0ubuntu2

---------------
gtk+2.0 (2.19.7-0ubuntu2) lucid; urgency=low

  * debian/patches/063_treeview_almost_fixed.patch:
    - change by Michael Vogt to add an ubuntu-almost-fixed-height-mode property,
      the change is required for software-center, adding as an ubuntu specific
      change for now until somebody comment on the upstream bug (lp: #514879)
  * debian/patches/064_initial_fileselector_select.patch:
    - change by Cody Russell to fix the default action not working in the
      gtkfileselector until you selected a directory (lp: #80755, #181788)
 -- Sebastien Bacher <email address hidden> Mon, 22 Mar 2010 14:23:46 +0100

Bug #181788 and this were both fixed in gtk and are dups