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 403985 - extracting doesn't work right when the location entry is displayed
extracting doesn't work right when the location entry is displayed
Status: RESOLVED DUPLICATE of bug 402349
Product: gtk+
Classification: Platform
Component: Widget: GtkFileChooser
2.10.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
Federico Mena Quintero
Depends on:
Blocks:
 
 
Reported: 2007-02-03 16:48 UTC by Sebastien Bacher
Modified: 2008-05-07 12:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Sebastien Bacher 2007-02-03 16:48:49 UTC
That bug has been described on https://launchpad.net/ubuntu/+source/file-roller/+bug/80755

"Binary package hint: file-roller

I'm not sure what's wrong, this may be an issue with the file selector, but extracting files with file-roller is a pain.

For example, I open an archive with just one file, click on "extract", and I get presented with a location selector; it's pointed by default on my desktop. If I now click OK (because I want to put the file on the desktop), it doesn't work. If I select another directory, then it works for that directory.
...
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.
..."
Comment 1 Paolo Bacchilega 2007-02-06 09:21:36 UTC
this is the way the filechooser works, reassigning to gtk+...
Comment 2 Ignacio Martin 2007-03-01 23:59:25 UTC
I can confirm this behavior.

I also want to point out that typing something in the location bar and press enter, it behaves like pressing the ok button. I don't know if this is intended, but it would be nice to provide the user the contents of the location he's typed in.
Comment 3 Sebastien Bacher 2007-10-03 22:11:04 UTC
distribution bug comment

"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."
Comment 4 Andrew Conkling 2008-05-07 12:35:07 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


*** This bug has been marked as a duplicate of 402349 ***