Bug 70831

Summary:	Bind mount doesn't allow to trash files and directories
Product:	File System	Reporter:	dbzix (dbz.gml)
Component:	VFS	Assignee:	fs_vfs
Status:	RESOLVED ANSWERED
Severity:	high	CC:	adobriyan, alan, c.buhtz, hans, netbox253, szg00000, toto_23
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	Debian 3.11.8-1	Subsystem:
Regression:	No	Bisected commit-id:

Description dbzix 2014-02-19 11:02:43 UTC

Hello.

I've asked a question here (https://unix.stackexchange.com/questions/115757/bind-mount-unable-to-delete-files-to-trash) about strange situation with deleting files from bind-mounted directories. Someone Ricky Beam supposed this is a kernel issue.

This is a quote of his words:
[QUOTE]
This is a linux kernel issue. It's not looking at the true super-block of the source and destination filesystems:

17926 rename("d1/foo", "d2/foo")        = -1 EXDEV (Invalid cross-device link)
Looks like the issue is in do_rename() (fs/namei.c):

    error = -EXDEV;
    if (oldnd.mnt != newnd.mnt)
            goto exit2;
*sigh*
[/QUOTE]

Could you please take a look at this issue and confirm or disprove this is a kernel issue?
Thank you very much!

Comment 1 dbzix 2014-02-19 11:10:17 UTC

I also found this old bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698640

Could you please check this and give me right direction?
Thank you once again!

Comment 2 Alexey Dobriyan 2014-03-09 13:03:40 UTC

rename(2) doesn't cross mountpoints.
That's how Unix always worked.

dup #14849

Comment 3 dbzix 2014-03-09 15:41:14 UTC

Alexey,

Okay, so is this kernel issue or not? What about my question about bind-mounted directories?
Does it relate to code provided above?

Thank you in advance!

Comment 4 Alexey Dobriyan 2014-03-09 17:07:34 UTC

You can not delete files to Trash because code internally does rename(2)
which doesn't work because rename formally crosses mountpoint.

Code can be improved, namely;
 * try rename(2)
 * if EXDEV, copy+unlink

Comment 5 Alexey Dobriyan 2014-03-09 17:09:47 UTC

kernel can be improved by option to allow rename to succeed
if rename crosses filesystem not mountpoint, but userspace code would have
the same problem: file and Trash on another fs.

Comment 6 dbzix 2014-03-09 21:34:58 UTC

Alexey, thanks for answer!

But this means that one cannot use bind-mounted directories 'normally', because there is no way to 'trash' files from such places, and the only way to delete files is permanent deleting without any possibility to restore such data.

And there is not much sense of using bind-mounted directories because of that obscure behavior. Am I right or I missed something?

Comment 7 Alexey Dobriyan 2014-03-10 10:00:50 UTC

Your best bet is to file a bug against your desktop environment vendor and ask to implement EXDEV:copy+unlink fallback.

Comment 8 dbzix 2014-03-10 10:19:09 UTC

Thanks!

Comment 9 Christian Buhtz 2021-05-18 19:41:58 UTC

Did someone opened a "bug against [any] desktop environment"?

Comment 10 ts 2022-01-12 10:14:42 UTC

Indeed, did someone open a bug against any desktop environment? Ubuntu is force-feeding snap to its users and snap requires mounted home directories (rather than symlinks).

Comment 11 Fab 2022-01-16 13:23:11 UTC

I hitted this recently. Bug opened against Xfce.

https://gitlab.xfce.org/xfce/thunar/-/issues/714