Trash handling on mounted BTRFS subvolumes


I’ve edited and re-posted this since the last post was (ironically) trashed for reading like a support request. I’ve removed the support question since I’m less concerned with workarounds than I am with how the system ought to handle trash on mounted BTRFS subvolumes. So here’s the edit:

I run Ubuntu on BTRFS. I also mount other BTRFS volumes regularly.

I typically use nautilus to delete files. I tap the delete button which, on the local filesystem, typically moves the selected file to /.local/share/Trash. The non-empty state of the trash bin is visually indicated (the Unity launcher full bin icon in 16.04 or the top bar icon of the Trash Gnome shell extension in 17.10). I can then empty trash easily at the end of my session.

This process is the same when deleting files from mounted FAT32, EXT4 and NTFS flash drives or hard disk drives. As expected, these files are typically moved to the hidden trash folder created in the root directory of the device. Again, visual indication is given for the non-empty state and emptying is easy.

BTRFS subvolumes behave a little differently. See, when deleting a file on a mounted BTRFS filesystem with multiple subvolumes, the file is moved to a hidden trash folder within each individual subvolume.

Now, this in itself is not a problem (is this something to do with subvolume ID level?). What is mildly irritating is that there is no visual indication of a non-empty state for trash on mounted BTRFS subvoumes. No notification. No icon. Nothing.

Here’s an example: take a mounted BTRFS filesystem called ‘VIDEO’. Within ‘VIDEO’ there are two subvolumes named ‘1080p’ and ‘720p’. Tap delete on a file from ‘1080p’ and it would move to /VIDEO/1080p/.Trash. The same action on a file from ‘720p’ would go into /VIDEO/720p/.Trash. Okay, no big deal. The issue is that neither of the above actions will present the user with any visual indication (whether fleeting or persistent) as to the non-empty state of their trash. Which in turn means that a disk can quickly and unwittingly be filled with unwanted files.

My current method of working around this is through the use of regular snapshots (what a tremendous feature of modern filesystems) alongside a per-subvolume trash folder removal script. Obviously, I’d prefer if I could simply empty trash, like I do with other filesystems.

Is this the expected behaviour for trash handling on BTRFS subvolumes?
If so, should this be the way Ubuntu handles trash on BTRFS subvolumes?



Hmmm. To me, this seems like a bug with whatever Desktop Environment (DE) you are using: “Trash icon does not change when using BTRFS”, or “Too many Trash folders in BTRFS”, etc.

I don’t understand how the Ubuntu Community is relevant to this issue, since the Ubuntu community maintains but one of Ubuntu’s DEs (Unity). The rest are upstream projects.

Perhaps you could explain why you think it’s not a bug, and why you think discussion here is the best place?

1 Like

My apologies, you’re correct.

I was mistaken as to whether this BTRFS trash-handling behaviour was intentional but it appears to be a bug. This is not the correct forum for bug discussion.

I’d like to file a bug report but I’m not sure whether this is even Ubuntu-specific. I’ll do some testing to determine the correct place to report the bug.


1 Like