Can't extract to non-local directories

[Mark Crutch]

Binary package hint: file-roller

With Gutsy, Fileroller can now open archives on non-local directories (e.g. smb:// paths in Nautilus), and can extract files to local directories using drag and drop (i.e. drag a file from Fileroller into Nautilus to extract it).

However Fileroller is unable to extract a file directly into a non-local directory, either by drag and drop, or by using the Extract button and navigating to the non-local directory.

For example, I have an archive on my local machine, and a Windows share bookmarked in the Places menu in Nautilus (smb://servername/sharename).

* Double click on the archive, Fileroller opens
* Select a file
* Click the Extract button, and navigate to the bookmarked Windows share
* Click the Extract button in the dialogue; the file is not extracted to the Windows share

* Alternatively, open a Nautilus window to the bookmarked location, via the Places menu
* Drag and drop the file to extract from Fileroller into the share; the file is not extracted to the Windows share

This is a minor annoyance, but it does mean that the user is required to understand the difference between local and remote directories. Ideally this distinction would not exist, so users could extract or drag and drop without needing to have any knowledge of the physical location of the destination folder.

[Pedro Villavicencio (pedro)]

Thanks for your report, I cannot reproduce this behavior. I can extract the files over the smb network just fine, to be confirmed by someone else getting the issue, thanks.

[Mark Crutch (markc-qsiuk)]

Just to clarify, I'm _not_ referring to an SMB share that has been mounted to a local mount point (e.g. via an entry in fstab, or via the "mount" command) - I'm only referring to remote directories accessed via a path in Nautilus that starts with smb:// (or ssh://, or ftp://). The following steps might be a better way to reproduce the problem - provided you can ssh to your local machine:

* Open a Nautilus window and press ctrl-L to focus the path
* Enter a path of "ssh://username@localhost" - replacing "username" as appropriate
* Enter your password when prompted, and tell it to remember the password until you log out
* You should now be looking at the filesystem of your local machine, but accessed via ssh
* Navigate to a directory in which you have full access rights (e.g. /home/username)
* Right click, select an option from the "Create Document" menu, then edit the document and save it - in other words, verify that you do have rights to create and edit files via that window

* Now open a second Nautilus window and navigate to a directory containing an archive of some sort
* Double-click on the archive to open Fileroller
* Drag a file from Fileroller into the first Nautilus window (the ssh window). You will be prompted to allow access for Fileroller, which you should then accept ("Allow once" or "Always allow")
* The file is _not_ created at the destination

If you were already doing something along these lines, then please leave this until someone else confirms the problem - but if you were extracting to a SMB share that has a real local mount point, it might be worth trying these steps instead to see if you can more easily reproduce the problem.

[Sebastien Bacher (seb128)]

Using the extract file-roller command works correctly, dnd doesn't work though, that might be a nautilus issue

[Anders Wallenquist (aw)]

I can confirm this problem with Gutsy, file-roller 2.20.1-0ubuntu1 and libgnome-vfs2.0-cil 2.16.0-7ubuntu1

[Alex Cornejo (acornejoc)]

I also confirm this behavior, although in a slightly different setting.

My home directory is:

/afs/myuniv/randomstuff/myusername

This is a very common setup in universities or corporations..

If I open any archive, I cannot drag and drop it anywhere, it just doesn't work, unless I drag'n'drop to /scratch (which is a local folder).

Again, I don't know if this bug is in nautilus or in the file-roller, but since nautilus drag'n'drop works correctly (at least between nautilus folders), I assume it is in file-roller.

[Sebastien Bacher (seb128)]

could you try if that's still an issue in hardy or intrepid?

[Mark Crutch (markc-qsiuk)]

It still seems to be an issue in Hardy (Fileroller version 2.22.3). In Intrepid (Fileroller version 2.23.5) it seems to work as desired, although I'll add the caveat that I was unable to make an SMB connection to my Windows box from Intrepid, so was only able to test it using SSH back into localhost.

[Sebastien Bacher (seb128)]

thank you for the update, the intrepid version uses gvfs and that seems to fix the issue, closing the bug

[Nando (nandox7-myrealbox)]

I'm using Ubuntu 8.10 with GNOME file-roller 2.24.1.
If i try to drag&drop a file inside a compressed archive from within file-roller and drop it in share in nautilus it gives an error stating i don't have the right permissions.
It's a windows share (smb://) and i have write permissions, as i usually extract to the desktop and after copy/paste to this same share.
Same behavior occurs if instead of the drag&drop i try to extract to the same share using the "extract" option and choosing the share from the "Places" list.

[Etuardu (etuardu)]

Sebastien Bacher: please note that the issue is not fixed in intrepid, at least for smb:// paths.

[Graham Lyon (eviltwin)]

I can also reproduce this bug whilst trying to extract to an ftp location (through drag and drop to nautilus or by pressing the "extract" button in file-roller. I can, however, extract them to a local directory and then drag them to the ftp directory in nautilus. I suspect that this bug is still a problem for a majority of users.

[michael perigard (overprescribed)]

I can reproduce this bug in jaunty dropping from file roller 2.26.0 to nautilus 2.26.0.

console yields:

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

file-roller 2.26.0-0ubuntu2
nautilus 1:2.26.0-0ubuntu4

[Sebastien Bacher (seb128)]

don't comment on a closed bug that will not be useful open a new bug if you have the issue on jaunty

[michael perigard (overprescribed)]

sorry, Sebastien, I read through the comments hastily and didn't notice where it had been marked as fixed. filing a new bug now.