Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 456515 - Dragging Files via NFS share moves instead of copy
Summary: Dragging Files via NFS share moves instead of copy
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus
Version: 10
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
: 492207 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-24 10:32 UTC by Andy Lawrence
Modified: 2015-03-03 22:33 UTC (History)
3 users (show)

Fixed In Version: 2.24.2-3.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 492207 (view as bug list)
Last Closed: 2009-04-06 20:23:59 UTC

Attachments (Terms of Use)

Description Andy Lawrence 2008-07-24 10:32:39 UTC
Description of problem:

Server machine is F6, client is F9.  When I drag a file from the server to
client it moves the files instead of copying?  If I move it back from the client
to the server is copies instead of moving?

Version-Release number of selected component (if applicable):
Client F9 Stable, all updates current.  Server F6.

How reproducible:


Steps to Reproduce:
1. Setup Client/Server NFS Share
2. Drag files in Gnome from server to client
Actual results:
From server to client files are moved not copied.  From client to server files
are copied.

Expected results:

In both cased files should be copied and not moved.

Additional info:

Comment 1 Andy Lawrence 2008-10-09 00:01:41 UTC
Tomas, is this a bug or perhaps new behaviour?

Comment 2 Andy Lawrence 2008-12-21 18:03:49 UTC
Same behaviour on a F10 client and server.

Comment 3 Andy Lawrence 2009-03-22 17:18:23 UTC
As a potential source for data loss due to unexpected behaviour I'm changing this to a medium severity.   

Several bug pings and several emails to the package maintainer with no response over the past ~8 months.

Comment 4 Tomáš Bžatek 2009-03-26 14:10:58 UTC
Just tested on F11 beta, nfs share mounted as /mnt/scratch, dragging a file from desktop to the nfs share and back always copies the file. No keyboard modificators used (Alt, Shift, Control).

Tested on another machine, running updated F10, same result.

There was relevant change in this matter some time ago:
which went into our packages before F10 was released.


Perhaps you could post relevant fstab record and `stat` of the two files (looking for "Device: 901h/2305d" string)

Comment 5 Tomáš Bžatek 2009-03-26 14:12:41 UTC
*** Bug 492207 has been marked as a duplicate of this bug. ***

Comment 6 Andy Lawrence 2009-03-26 14:40:31 UTC
Tomas, thanks for the information, here is what you requested.  My behaviour is still the same, it is moving the file from the server to the client and copying from the client to the server.

This operation was done from the client (all updates) with the following:

Mounted as:	/main	nfs rw 0 0

File property:
Device: fd00h/64768d

I will provide any information requested, please ask if I misunderstood.


Comment 7 Andy Lawrence 2009-03-26 18:16:48 UTC
This appears to be a hot topic:

I would agree that operations on the local drive are file moves and any remote mounted media be a file copy.  In my case, the remote mount copy/move is both depending on the direction!

Comment 8 Tomáš Bžatek 2009-03-27 09:49:36 UTC
I've read through the upstream bug and I think everything has been already said there. Noticed some of our Gnome usability experts are involved in the discussion and they have authoritative voice in this case.

You can however add your opinion there, describing your problem in detail, it seems there are different use cases. There's a difference between local disk mounts, remote mounts from fstab and gvfs mounts. You can expect slightly different behaviour in F11 since we've moved to DeviceKit.

The output of stat command will be needed for both sides.

Comment 9 Andy Lawrence 2009-03-28 00:04:31 UTC
Output of stat from the server, then from the client once moved (as in it moves the file rather than copy).

Device: 820h/2080d

The Client once moved (dragged from the NFS share to the client, which should have copied):
Device: fd00h/64768d


Comment 10 Alexander Larsson 2009-03-31 09:08:29 UTC
The default for nautilus is supposed to be "copy" if  the filesystems are different. This is detected by comparing the device nr when stat:ing the source and the destination directory. Are these different?

Also, exactly how are you dropping the file? To an open window displaying the target, or in some other way?

Comment 11 Andy Lawrence 2009-03-31 10:24:17 UTC
Hi Alexander!

Yes, I'm simply opening the NFS share from within Gnome and dragging the file to my desktop.

Here is the stat from a different file than used above:

While the file was still on the server:
Device: 820h/2080d

Drag and drop to my desktop which moved the file:

Device: fd00h/64768d

Then drag and drop back to the server which copied the file:

Device: 820h/2080d


Comment 12 Alexander Larsson 2009-04-02 12:11:08 UTC
Thats really weird. I can't reproduce here.
Can you give me the output of:
gvfs-info -a "id::filesystem" <filename>

on a file on nfs and one in your homedir (which i assume is a local disk, right?)

Comment 13 Andy Lawrence 2009-04-02 13:04:28 UTC
No Problem:

A file on the server:

type: unknown
size: 0
  id::filesystem: l2080

A file in my home dir which is local:

type: unknown
size: 0
  id::filesystem: l64768

If that doesn't tell you what you need to know I'll get you in.  Please email me at the address listed.


Comment 14 Alexander Larsson 2009-04-02 13:17:15 UTC
Oh, I think I know. 

Can you instead of dropping on the desktop drop on a nautilus window showing ~/Desktop? Does this work?

If so, then this is fixed in F10.

Comment 15 Alexander Larsson 2009-04-02 13:20:11 UTC
Oh, i see you still get it in F10. Anyway, please test that anyway

Comment 16 Andy Lawrence 2009-04-02 13:48:06 UTC
Dropping directly into ~/Desktop still tries to move the file.


Comment 17 Alexander Larsson 2009-04-02 14:14:08 UTC
Hmmm it seems we also move by default when you drag something to one of its parent folders. Not sure exactly why this is, but I'm assuming you're not hitting that behaviour? i.e. where is the NFS mount mounted?

Comment 18 Andy Lawrence 2009-04-02 14:26:10 UTC
The server has an XFS volume mounted to /main.  The client has the volume mounted as: /main nfs rw 0 0

Could it be because the mount names are the same?  That wouldn't explain why it copies the file from the Client to the server?

Comment 19 Alexander Larsson 2009-04-02 14:40:53 UTC
And your homedir is not mounted under /main ?

Comment 20 Alexander Larsson 2009-04-02 14:41:56 UTC
(or symlinked into it or similar)

Comment 21 Andy Lawrence 2009-04-02 14:43:53 UTC
Correct, home dir is mounted as default F10 LVM install.

Comment 22 Andy Lawrence 2009-04-02 22:01:27 UTC
Alex, I have figured out what is causing this.  I have a symbolic link to my server (/main) on my desktop.  When I open the NFS share with the symbolic link it moves the file, when I open it from FileSystem > main > somefiletocopy it copies it.

Comment 23 Alexander Larsson 2009-04-03 08:38:47 UTC
Yeah, that would be the "move if dragging to a parent folder behaviour.
I'm not sure why we're doing that actually...

Comment 24 Andy Lawrence 2009-04-03 09:43:45 UTC
Considering that it really isn't the parent folder I'm guessing this still classifies as a bug?

Comment 25 Alexander Larsson 2009-04-06 08:13:17 UTC
"a parent" == parent, grandparent, etc...

However, I think that behaviour is kinda weird. I'm gonna go looking in the source history and try to figure out why it was added.

Comment 26 Alexander Larsson 2009-04-06 08:25:04 UTC
Ah, i see. Here is the source of the change:

Basically if you try to move a mount root from a directory /foo/mount to /foo the mount is on a different filesystem, so it would copy. This means you can't e.g. move a mounted directory on the desktop to another position on the desktop.

However, the behaviour has since then changed to be a recursive is-parent. I'll fix that back.

Comment 27 Alexander Larsson 2009-04-06 08:31:09 UTC
Fixed in upstream, will pull into fedora in next upstream release.

Comment 28 Andy Lawrence 2009-04-06 10:07:11 UTC

Is this nautilus or gvfs that required the fix?

Comment 29 Fedora Update System 2009-04-06 13:36:08 UTC
nautilus-2.24.2-3.fc10 has been submitted as an update for Fedora 10.

Comment 30 Tomáš Bžatek 2009-04-06 13:37:49 UTC
I've backported the upstream fix to F10 packages + built new rawhide nautilus pkgs.

Comment 31 Fedora Update System 2009-04-06 20:23:54 UTC
nautilus-2.24.2-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 32 Andy Lawrence 2009-04-06 20:40:12 UTC
I can confirm this issue is now fixed, big thanks to all.

Note You need to log in before you can comment on or make changes to this bug.