Bug 70831 - Bind mount doesn't allow to trash files and directories
Summary: Bind mount doesn't allow to trash files and directories
Status: RESOLVED ANSWERED
Alias: None
Product: File System
Classification: Unclassified
Component: VFS (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: fs_vfs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-19 11:02 UTC by dbzix
Modified: 2022-01-16 13:23 UTC (History)
7 users (show)

See Also:
Kernel Version: Debian 3.11.8-1
Subsystem:
Regression: No
Bisected commit-id:


Attachments

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

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