Bug 456515

Tomas, is this a bug or perhaps new behaviour?

Same behaviour on a F10 client and server.

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.

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: http://svn.gnome.org/viewvc/nautilus?view=revision&revision=14376
which went into our packages before F10 was released.

nautilus-2.25.92-1.fc11
gvfs-1.1.7-5.fc11

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

*** Bug 492207 has been marked as a duplicate of this bug. ***

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:
nautilus-2.24.2-2.fc10.x86_64
gvfs-1.0.3-6.fc10.x86_64

Mounted as:
192.168.2.41:/main	/main	nfs rw 0 0

File property:
Device: fd00h/64768d

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

Thanks
Andy

This appears to be a hot topic:

http://bugzilla.gnome.org/show_bug.cgi?id=143746

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!

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.

Output of stat from the server, then from the client once moved (as in it moves the file rather than copy).

Server: 
Device: 820h/2080d

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

Thanks

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?

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


Thanks
Andy

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?)

No Problem:

A file on the server:

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

A file in my home dir which is local:

type: unknown
size: 0
attributes:
  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.

Thanks

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.

Oh, i see you still get it in F10. Anyway, please test that anyway

Dropping directly into ~/Desktop still tries to move the file.

Thanks

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?

The server has an XFS volume mounted to /main.  The client has the volume mounted as:

192.168.2.41:/main /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?

And your homedir is not mounted under /main ?

(or symlinked into it or similar)

Correct, home dir is mounted as default F10 LVM install.

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.

Yeah, that would be the "move if dragging to a parent folder behaviour.
I'm not sure why we're doing that actually...

Considering that it really isn't the parent folder I'm guessing this still classifies as a bug?

"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.

Ah, i see. Here is the source of the change:

http://bugzilla.gnome.org/show_bug.cgi?id=61269

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.

Fixed in upstream, will pull into fedora in next upstream release.

Thanks!

Is this nautilus or gvfs that required the fix?

nautilus-2.24.2-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/nautilus-2.24.2-3.fc10

I've backported the upstream fix to F10 packages + built new rawhide nautilus pkgs.

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.

I can confirm this issue is now fixed, big thanks to all.