This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 436160 - file deletion probs "Not on the same file system."
file deletion probs "Not on the same file system."
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
10
All Linux
low Severity high
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-05 13:12 EST by Ralf Corsepius
Modified: 2015-03-03 17:32 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 05:38:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
log as requested (27.48 KB, application/octet-stream)
2009-04-02 09:31 EDT, Ralf Corsepius
no flags Details

  None (edit)
Description Ralf Corsepius 2008-03-05 13:12:50 EST
Description of problem:

I can't move certain files to "Trash" using nautilus using drag'n'drop.

nautilus aborts with "Error: Not on the same file system."

This message is apparently wrong.
My Trash-folder (~/.Trash) is on the same filesystem as the file I am trying to
delete.


Version-Release number of selected component (if applicable):
nautilus-2.20.0-8.fc8


How reproducible:
Always.

Steps to Reproduce:
1. mkdir /tmp/foo
2. touch /tmp/foo/bar
3. Open /tmp/foo using nautilus
4. Choose Edit/Move To Trash
  
Actual results:
cf. above.

Expected results:
Function.

Additional info:
I am inclined to think nautilus might have issues with autofs. Though my $HOME
is on the same physical partition as /tmp, it is automounted as /users/<users>
from /home/<user> (I.e. HOME=/users/<user>).
Comment 1 Bug Zapper 2008-11-26 05:01:43 EST
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
Comment 2 Ralf Corsepius 2008-11-26 05:08:37 EST
bug still present in FC10. 

Nautilus or whatever component below is responsible is as broken as it used to be.
Comment 3 Matthew Mosesohn 2009-01-28 10:56:40 EST
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
Comment 4 Alexander Larsson 2009-03-31 04:56:27 EDT
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?
Comment 5 Ralf Corsepius 2009-03-31 05:46:19 EDT
(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).
Comment 6 Alexander Larsson 2009-04-02 08:31:36 EDT
Whats the output of:
stat /tmp/foo
stat /users/ralf/.local/share/Trash
Comment 7 Alexander Larsson 2009-04-02 08:32:51 EDT
oh, and:
stat /users/ralf
Comment 8 Ralf Corsepius 2009-04-02 08:41:05 EDT
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
Comment 9 Alexander Larsson 2009-04-02 09:13:13 EDT
Weird. Can you try:
strace -o log gvfs-trash /tmp/foo
and attach the log?
Comment 10 Ralf Corsepius 2009-04-02 09:31:40 EDT
Created attachment 337809 [details]
log as requested
Comment 11 Ralf Corsepius 2009-04-02 09:33:10 EDT
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
Comment 12 Alexander Larsson 2009-04-02 10:05:45 EDT
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.
Comment 13 Alexander Larsson 2009-04-02 10:18:45 EDT
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.
Comment 14 Ralf Corsepius 2009-04-02 10:33:02 EDT
(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
Comment 15 Alexander Larsson 2009-04-02 12:25:04 EDT
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.
Comment 16 Alexander Larsson 2009-04-02 13:07:08 EDT
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.
Comment 17 Ralf Corsepius 2009-04-02 22:48:58 EDT
(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.
Comment 18 Alexander Larsson 2009-04-03 04:34:13 EDT
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.
Comment 19 Ralf Corsepius 2009-04-03 05:26:35 EDT
(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).
Comment 20 Alexander Larsson 2009-04-06 04:17:36 EDT
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.
Comment 21 Ralf Corsepius 2009-04-06 05:14:48 EDT
(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.
Comment 22 Ralf Corsepius 2009-04-06 05:28:56 EDT
Reopening, increasing seriousness.
Comment 23 Alexander Larsson 2009-04-06 05:38:50 EDT
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.

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