Bug 436160

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

bug still present in FC10. 

Nautilus or whatever component below is responsible is as broken as it used to be.

This bug exists in Nautilus in RHEL 5.2
Scenario:
mount server1:/data /mnt/data
use nautilus to browse to /mnt/data and create a folder foo
move folder foo to trash


Expected behavior should be:
Nautilus attempts to create .Trash-$username on server1:/data and mv $file .Trash-$username

Does this happen only on dnd to trash?
Or does it also happen when you select trash from the menus?
What kind of filesystem is it?

(In reply to comment #4)
> Does this happen only on dnd to trash?
No.

> Or does it also happen when you select trash from the menus?
Yes. 

It happens in both cases.

> What kind of filesystem is it?  

ext3 under Fedora (currently FC10)

As I already wrote above, I think the cause is related to me using autofs-mounted homes:

# mount
... 
/home/ralf on /users/ralf type none (rw,bind)
...

i.e. HOME=/users/ralf, which is a bind-mount to /home/ralf on the local disk on this paritcular machine, while it is an nfs-mount on other machines.

In this setup, nautilus refuses to "move to trash" /tmp/foo.txt. 
To me, this behavior doesn't make any sense. "move"'ing files is always possible, even between devices (which doesn't apply here).

Whats the output of:
stat /tmp/foo
stat /users/ralf/.local/share/Trash

oh, and:
stat /users/ralf

Here we go:

# stat /users/ralf /users/ralf/.local/share/Trash /home/ralf /tmp/foo

  File: `/users/ralf'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d	Inode: 50921507    Links: 58
Access: (0750/drwxr-x---)  Uid: ( 8690/ralf)   Gid: ( 7020/    amos)
Access: 2009-04-02 14:37:09.000000000 +0200
Modify: 2009-04-02 05:35:39.000000000 +0200
Change: 2009-04-02 05:35:39.000000000 +0200

  File: `/users/ralf/.local/share/Trash'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d	Inode: 50924048    Links: 4
Access: (0700/drwx------)  Uid: ( 8690/ralf)   Gid: ( 7020/    amos)
Access: 2009-03-26 06:33:12.000000000 +0100
Modify: 2009-03-04 07:23:58.000000000 +0100
Change: 2009-03-04 07:23:58.000000000 +0100

  File: `/home/ralf'
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: fd00h/64768d	Inode: 50921507    Links: 58
Access: (0750/drwxr-x---)  Uid: ( 8690/ralf)   Gid: ( 7020/    amos)
Access: 2009-04-02 14:37:09.000000000 +0200
Modify: 2009-04-02 05:35:39.000000000 +0200
Change: 2009-04-02 05:35:39.000000000 +0200

  File: `/tmp/foo'
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d	Inode: 113934346   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 8690/ralf)   Gid: ( 7020/    amos)
Access: 2009-04-02 14:37:16.000000000 +0200
Modify: 2009-04-02 14:36:59.000000000 +0200
Change: 2009-04-02 14:36:59.000000000 +0200

Weird. Can you try:
strace -o log gvfs-trash /tmp/foo
and attach the log?

Created attachment 337809 [details]
log as requested

FYI: This happened when creating the log
# strace -o log gvfs-trash /tmp/foo
Error trashing file: Unable to trash file: Invalid cross-device link

Very weird. We stat the files to know that they are the same mount, this should mean that a rename should succeed, but then we get:

rename("/tmp/foo", "/users/ralf/.local/share/Trash/files/foo.3") = -1 EXDEV (Invalid cross-device link)

So, the kernel refuses to move the file even though its on the same filesystem. It seems the bind mount makes it think they are not the same...

I don't know how to detect this ahead of time though... So, although we could fix the error message we can't really avoid allowing trash in this case.

from man 2 rename:

EXDEV  oldpath and newpath are not on the same mounted file system.  (Linux permits a filesystem  to be mounted at multiple points, but rename() does not work across different mount points, even if the same file system is mounted on both.)

I guess the same is true for bind mounts... Teh suck.

(In reply to comment #13)
> from man 2 rename:
> 
> EXDEV  oldpath and newpath are not on the same mounted file system.  (Linux
> permits a filesystem  to be mounted at multiple points, but rename() does not
> work across different mount points, even if the same file system is mounted on
> both.)
> 
> I guess the same is true for bind mounts... Teh suck.  

Well, a matter of perspective :)

Another similar error occurs when "move to trash" a file from a different partition with r/o root:

# strace -o log2 gvfs-trash /srv/backup/scratch/foo 
Error trashing file: Unable to find or create trash directory

In this case, /srv/backup is an external USB-drive
# df
...
/dev/sdb1            480719056 373550192  82749664  82% /srv/backup

The error happens, because gvfs-trash wants to create a .Trash folder inside of the root of the external device:
...
stat("/srv/backup/scratch", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/srv/backup", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/srv", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/srv/backup/.Trash", 0x7fffbe56e480) = -1 ENOENT (No such file or directory)
lstat("/srv/backup/.Trash-8690", 0x7fffbe56e510) = -1 ENOENT (No such file or directory)
mkdir("/srv/backup/.Trash-8690", 0700)  = -1 EACCES (Permission denied)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff5b656f000
write(1, "Error trashing file: Unable to fi"..., 62) = 62

Well, thats a different thing. If you don't have a .Trash and we can't create one we don't support trashing on that filesystem.

However, we should detect this and disable trash in the ui.

I commited a fix upstream that returns a NOT_SUPPORTED error in the EXDEV error case. This should let nautilus fallback on delete instead of trashing.

Kinda unfortunate, but I don't see a better solution. You could use a symlink instead of a bind mount maybe.

(In reply to comment #15)
> Well, thats a different thing.
Yep - it's a side effect of Gnome's (IMO silly) way to temporarily store "deletion candidates".

Another ugly effect of this: Spraying .Trash folders on removable media, such as SD cards and memory sticks.

> If you don't have a .Trash and we can't create
> one we don't support trashing on that filesystem.
>
> However, we should detect this and disable trash in the ui.  
IMO, the better question is: Why does one have to create these .Trash folders at all?

(In reply to comment #16)
> I commited a fix upstream that returns a NOT_SUPPORTED error in the EXDEV error
> case. This should let nautilus fallback on delete instead of trashing.
> 
> Kinda unfortunate, but I don't see a better solution.
>
> You could use a symlink
> instead of a bind mount maybe.
Well, that's what autofs did ca. a decade ago. Modern autofs uses bind-mounts.

If you're interested in how trash work, there is a spec at:
http://freedesktop.org/wiki/Specifications/trash-spec

> Well, that's what autofs did ca. a decade ago. Modern autofs uses bind-mounts.  
Ok. So modern autofs users don't get trash functionallity then.

(In reply to comment #18)
> If you're interested in how trash work, there is a spec at:
> http://freedesktop.org/wiki/Specifications/trash-spec
> 
> > Well, that's what autofs did ca. a decade ago. Modern autofs uses bind-mounts.  
> Ok. So modern autofs users don't get trash functionallity then.  

Yes, they are affected by the naive and semi-functional stuff contained in Gnome.

May-be you should have a look into "mv"'s and "cp"'s source code - moving a file is a little more than a naive implementation using plain rename.

For comparison: A plain 
mv /tmp/foo ~/.local/share/Trash/
"simply work"


Finally: This stuff also fails on nfs-mounted homes (and other directories).

I'm well aware of how mv is implemented. Moves across mountpoints work fine in gvfs and nautilus, that is not the point. The problem is that the alternative implementation to rename() for moving a file is not a good match for what people expect from a trash operation (fast, doesn't waste resources, very low chance of i/o failure). So, we're explicitly not supporting trashing across mounts.

btw, you are not helping your case by acting like a jerk.

(In reply to comment #20)
> btw, you are not helping your case by acting like a jerk.  
WHAT?

The jerk is you, because
a) Above you wrote "bind mounts suck" - This is a foul statement.
Correct is: Your implementation is too naive to handle such cases.

Reusing your wording: Your implementation sucks.


b) You closed this BZ, despite you are aware about the deficiencies of your implementation.

By having done so, you made very clear you are ignorant about your work's users.

Reopening, increasing seriousness.

I didn't say bind mount suck. I said it sucks that hey have this the behavior wrt renames, as it leads to not being able to implement trash across them in a sane way. 

My implementation of trashing has an explicit design choice to not do trashing via copy. This bind mount behaviour makes trashing without copying not possible. Thus, the design is to not support this. An alternative design choice is to allow trashing via copying, but it has other disadvantages. 

I'm not at all ignorant about this. On the contrary, i'm well aware of both the sides of the coin when doing this decision. Its you who choose to only be aware of one side.