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 578892 - file-roller only creates empty folder when extracting to network-share
file-roller only creates empty folder when extracting to network-share
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
2.26.x
Other All
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2009-04-13 23:41 UTC by Andreas Moog
Modified: 2010-05-18 13:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Description Andreas Moog 2009-04-13 23:41:19 UTC 
Please describe the problem:
"In Gnome File Browser (Nautilus 2.26.1), you can right-click on an archive file (.zip, .tar.gz, .tgz) and select "Extract Here". This works as expected in a local folder.

When trying to use "Extract Here" on an archive file over a Network Folder (using Connect To Server...), this only creates an empty folder.

I can reproduce this using a .zip, .tgz, .tar.gz files using a network share either over SMB or SSH. I haven't tried other archive types or mount types. I have tried with several different archive packages."

Same happens when opening the archive with file-roller and extracting from there.

Steps to reproduce:
1. Open network (smb/ssh) shared folder
2. right-click "extract here" on archive



Actual results:
Empty Folder is created

Expected results:
The folder should contain archive contents.

Does this happen every time?
Yes

Other information:
Reported on Launchpad:
https://bugs.launchpad.net/bugs/360598
Comment 1 Andreas Moog 2009-04-13 23:56:59 UTC 
Ok, got some more Information. When opening the archive on the remote I get:

Gtk-WARNING **: Operation not supported by backend

While extracting, there is a

(file-roller:18563): GLib-GIO-CRITICAL **: g_file_new_for_uri: assertion `uri != NULL' failed

Could this be a GVFS-issue?
Comment 2 Pedro Villavicencio 2009-04-14 15:06:29 UTC 
Got the same with an FTP if you click on extract there's actually no extraction and the same message is throw on the console.
Comment 3 Chris Coulson 2009-04-26 20:12:01 UTC 
Here is a backtrace for this with G_DEBUG=fatal_criticals

+ Trace 214821

  • #0 *__GI_raise
    at ../nptl/sysdeps/unix/sysv/linux/raise.c line 64
  • #1 *__GI_abort
    at abort.c line 88
  • #2 IA__g_logv
    at /build/buildd/glib2.0-2.20.1/glib/gmessages.c line 506
  • #3 IA__g_log
    at /build/buildd/glib2.0-2.20.1/glib/gmessages.c line 526
  • #4 IA__g_file_new_for_uri
    at /build/buildd/glib2.0-2.20.1/gio/gfile.c line 4887
  • #5 g_directory_copy_current_child
    at gio-utils.c line 1196
  • #6 g_directory_copy_next_child
    at gio-utils.c line 1215
  • #7 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 1814
  • #8 g_main_context_iterate
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2448
  • #9 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c line 2656
  • #10 IA__gtk_main
    at /build/buildd/gtk+2.0-2.16.1/gtk/gtkmain.c line 1205
  • #11 main
    at main.c line 309 






Comment 4


Tomas Bzatek





          2010-05-18 13:42:13 UTC
        



I believe this is fixed in master by the following commit:

commit 33c21fc3647af32de5a9c9d49e33765a526910f5
Author: Tomas Bzatek <tbzatek@redhat.com>
Date:   Wed May 12 13:54:29 2010 +0200

    Bring back support for file caching when gvfs-fuse-daemon is not available
    
    The commit 73fa5d77a60861cd35c6f3425d27c88061af081c introduced trouble
    when user was trying to work with archives on remote GIO mounts and
    not having the fuse daemon running. This led to segfaults and error messages.
    
    Please see bug #617769 for details.


I'm going to close this bugreport now, feel free to reopen it if the problem persists.