Nautilus tries to copy a dragged file into Network on hover and freezes

[VF]

Binary package hint: gvfs

Using hardy, gvfs 0.2.1-1ubuntu1, nautilus 1:2.22.0-0ubuntu3

Steps to reproduce:
1. Open nautilus to the default browser view.
2. Try to drag and drop a file from the browser window onto the desktop window, making sure to move it over the network servers item in the sidebar

Results:
Nautilus freezes temporarily
Error message is "There was an error copying the file into network:///. - Operation not supported by backend".

Nautilus shouldn't try to copy a file on a simple hover. Seems like a nautilus bug but I've never seen it until gvfs showed up.

[Sebastien Bacher (seb128)]

Thank you for your bug report. Not confirming, it doesn't display any message there. Do you unclick while being on the network entry?

[VF (vfiend)]

No, it freezes and does the compiz 'gray out' for a few seconds when the file cursor is hovered over the network servers entry. This makes dragging and dropping files difficult.

[Sebastien Bacher (seb128)]

what about the error message you described? this bug description is confusing

[VF (vfiend)]

Huh, I was about to make a video to demonstrate and I can't reproduce it now. Maybe an update I did earlier fixed it or maybe I'm just crazy. Either way, nevermind this bug

[marwal (marwal)]

I have the same problem with the behaviour of Nautilus.

If I grab a file from the Desktop and want to drag-n-drop it into the folder currently opened in Nautilus... when the mouse-pointer "holding" the file passes Nautilus SidePane (showing Places), Nautilus acts as if I dropped the file onto "Network Servers" and spends 20 seconds trying to copy it there.
Then throws two dialogs:"preparing file operation" and "Error while copying to "Network"."

[Christian Dannie Storgaard (cybolic)]

This still occurs on my fully updated Hardy installation, so the bug hasn't gone away yet.

[Sebastien Bacher (seb128)]

could you describe what you do exactly and what error you get?

[Christian Dannie Storgaard (cybolic)]

It's pretty well described in the bug description - I get the exact same error.

For some reason though, I couldn't reproduce the bug today, though I haven't updated anything.

[JoeBaloney (joe-baloney)]

I had the same thing just now. I have Ubuntu server 8.04 sharing a partition via samba. I connected to the drive from "places->network" and browsing to it. I then put in a blank cdrom and tried to drag some files from the samba drive directly to the blank cd, the first folder copied, but as soon as it attempted to copy a file I got the "operation not supported by backend"

After trying a few more times, I copied the files from my samba drive to my desktop, then from the desktop to the cdrom worked just fine.

[JoeBaloney (joe-baloney)]

I forgot to mention, my client is 8.04 installed the day before yesterday. I don't know if this is related, but when I tried to mount the drive as CIFS (which worked before I upgraded to 8.04), I got the follwing error:

sudo mount -t cifs //media/hda1 /media/media-hda1 -o username=tward
[sudo] password for tward:

mount: wrong fs type, bad option, bad superblock on //media/hda1,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)
       In some cases useful info is found in syslog - try

But using places->network and browsing worked fine.

[Kilz (kilz)]

I am running Hardy amd64, getting the same error occasionly. I was dragging a deb file and it froze. Here is all the text from the box.

Error while copying "swiftdove-2.0.0.12-2_athlon64-64bit_AMD64.deb".

There was an error copying the file into network:///.

Show more details
Operation not supported by backend

Three buttons cancel skip All and Skip

The bug is intermittent when dragging flies from one window to another. The drag may go over mounted nfs shares listed in the side pane as shortcuts/bookmarks in nautilus as I have 10 listed.

[Ljvillanueva (ljvillanueva)]

This has happened to me too using Hardy, but did no see this with Gutsy.

When trying to copy files or folders between my computer and a network connection (sftp, sshfs or ftp) sometimes (I can't find a pattern) the Nautilus windows gray out and then I get the error message "Operation not supported by backend". I'm guessing its a problem getting a network connection to do the transfer.

[CKX (chester-kollschen)]

I encounter the temporary Nautilus freeze, too, when dragging files over the "Network" item in the "Places" sidebar panel.

I observed this issue a bit and hope my results can help to clarify things a bit.

First, it does not matter how many or what kind of files you drag. It also does not matter whether you drag them from or to the Nautilus window. The mentioned freeze may occur when you start an arbitrary drag-action and hover the items over the "Network" item in Nautilus' "Places" sidebar panel.

What happens after the freeze depends on your reaction:

If you are patient enough and keep the mouse button pressed all the time during the freeze until Nautilus wakes up again, you can continue the drag-action normally and drop the items at the desired location without any problems.

But if you release the mouse button during the freeze, X will post a MOUSE_UP event to the event queue. When Nautilus wakes up after its freeze, it will interprete that event as an intended drop. So it will try to copy the dragged items to "Network" which is where the mouse pointer was when the freeze began. However, copying to "Network" is an unsupported action and will fail with the mentioned error message.

This is what I think may cause that freeze:

Applications usually analyze the data that is being dragged over them to signal if they would accept the data to be dropped here. This is shown to the user as a symbol next to mouse cursor which can, for example, be a forbidden sign.

Since hardy, Nautilus uses gvfs instead of gnome-vfs. gvfs mounts its backends lazily when they are needed. I think there may be a problem with the implemenation of Nautilus' "Network" item. If it is uninitialized, it may take a while to scan the network for nodes. If the user drags any data over the "Network" item, Nautilus asks the "Network" item if the data would be accepted here for drop. If "Network" is uninitialized, it will initialize at this very moment, scanning the network and causing the temporary freeze.

[A. Walton (awalton)]

The problem is actually much more mundane: the sidebar in Nautilus currently does synchronous I/O, which takes a while to complete, and locks the process for the duration. (This is the reason synchronous I/O is forbidden within Nautilus. There's another instance where this can happen when interacting with the pathbar that we haven't resolved yet either).

The "Network" backend can take some time to enumerate "files" due to the smb-browse backend taking a bit of time to enumerate "files", but this should be hidden behind Nautilus' design. There's currently no way to avoid that latency, though there's probably more places we can hide it in the network backend (e.g. by using completely asynchronous I/O there too, but I'm not sure how well that's going to fly with GVFS' threading model, something that needs to be asked of Alex Larsson, who designed GVFS but is currently on leave).

The bug in Nautilus would theoretically manifest and will block on any URI dragged over the places sidebar, but in practice, the local filesystems return their id::filesystem keys so fast that you don't see it happening. gvfsd-network currently doesn't even return this key, which should be an early out, but something else is going on that it's apparently not, I'll try to experiment with adding this key to the backend over the weekend to see if we can't speed things up until we rewrite the DnD code in Nautilus.

[Michael Rooney (mrooney)]

Yes, I must admit this is supremely annoying, not only because it causes such a delay in which you can't use nautilus, but because it also destroys your drag state and have to do it over, being careful to not hover of the network. This happens to me on almost a daily basis. I will attach a screenshot of the error message that I get in 8.04.1.

[Michael Rooney (mrooney)]

So this was fixed in nautilus 2.25.1 according to upstream; is there any chance of patching the Hardy nautilus to get this fix? We will probably also have to apply this patch to Intrepid as well, since that will have 2.24 and not 2.25 IIUC. Creating a patch would be worth the effort I think, since a) we can't just ignore it since it will still exist in Intrepid and b) Hardy is an LTS so not fixing this issue there will cause grief for years to come.

Any thoughts A. Walton, or anyone else?

[Michael Rooney (mrooney)]

And a second question, will this stop the error message from appearing that I attached in comment #16, or will it just appear later when/if the async operation fails? That would be quite confusing for users if an error message popped up after a delay.

[Sebastien Bacher (seb128)]

nautilus 2.25 is in intrepid, closing the bug. the change is not trivial and not likely to be backported to hardy

[Sebastien Bacher (seb128)]

the changes seems to be http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14376 but that's not sure it would apply to the stable code since the unstable serie got some reorganisation before this change

[Michael Rooney (mrooney)]

I thought it was the 2.23 series that is currently in Intrepid (http://packages.ubuntu.com/intrepid/nautilus), with plans for 2.24. Gnome 2.26 won't be until Intrepid+1, right? Am I missing something?

[Sebastien Bacher (seb128)]

there is no 2.25, the current version is 2.23.5 and upstream did a typo apparently, there is no need to focus so hard on numbers, the changes has been commited to svn in the unstable serie which is updated in intrepid

[Pedro Villavicencio (pedro)]

this is fixed on intrepid now.