4

Nautilus trash do not move file to trash bin on btrfs file system instead it deletes them permanently. Thunar seems to do the same thing, and it seems related to lower level library implementation of the trash bin.

I added a new directory ~/.local/share/Trash/ that allows the file manager Nautilus and Thunar to use the trash bin however it works only for deletion that occurs from the same subvolume. Trashing from any other btrfs subvolume or partition triggers permanent deletion.

Calibre, the ebook library manager, has a different behavior. My calibre library is on a different subvolume than my home. When I delete books from the Calibre manager, it moves the books to a hidden directory .Trash-1000 under the root of the subvolume where the Calibre library is stored. However this hidden directory is not taken into account by the trash bin therefore the books stay hidden occupying space until I finally discovered them by chance. I don't think Calibre is wrong here because it looks like the way trash bins are managed on external media in ext3/4 file system.

Emacs function (delete-file) manage to use the trash bin for different subvolumes and even more amazing it uses the trash bin ~/.local/share/Trash/ for other partition on different disks. So it does the job perfectly.

  • Do you know a desktop file manager than could work with the trash bin across different btrfs subvolume ?
  • Do you know a way to prevent some softwares such as calibre to move the files to a hidden spot while you think they are deleted ?
  • It seems the libraries gvfs and glib/gio are used to manage the trash bin. The softwares I mentioned are all calling different OS functions when it comes to file deletion and the result is not consistent. Anyone has tracks about how trash bins could be managed correctly ?

As far as my research goes, the problem seems to be older than 5 years https://bugs.launchpad.net/glib/+bug/1442649 I have been using btrfs for a long time with this downside, but I am curious to see how other people deal with this problem especially since btrfs becomes more popular and seems to be proposed in some linux distribution installer.

GNU/Linux 5.15.2-2 Manjaro Gnome: 41.1

Improve this question
5
  • To be honest, trashing across subvol or filesystem kinda sucks as copying (of actual data) will occur. (I'm not sure if reflink or so across subvols is impossible though.) IMHO it's more of a preference matter than a bug-or-not. Commented Dec 9, 2021 at 8:55
  • With a hidden .Trash at the root of the btrfs partition no copying is required moving files across subvolumes of the same partition should not trigger write operations as snapshots are working that way. If the Trash bin aggregates all the .Trash hidden folders this would be similar to ext4. Commented Dec 9, 2021 at 10:32
  • I think you forgot the complicacy of ownership and permission. It's doable at best. Commented Dec 9, 2021 at 10:38
  • 1
    gitlab.gnome.org/GNOME/glib/-/issues/1885 Issue still alive in 2023. Commented Jul 7, 2023 at 10:50
  • @Majal thanks for the pointer. I haven't found any satisfying solution and I forgot about the issue since I do most of my file management from Emacs and the terminal 99% of the time. However it would be nice to report the problem to the right place for a more casual usage of Btrfs on Linux with graphical file manager such as Nautilus and Thunar. Commented Jul 8, 2023 at 23:21

1 Answer 1

Reset to default
2

I finally found the solution for Gnome⩾47, mount your subvolume with the option x-gvfs-trash for instance

sudo mount -t btrfs -o defaults,subvol=data,x-gvfs-trash /dev/sda1 /media/data
Improve this answer
1

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.