gio inappropriately stopped trashing files on certain volumes
Background
My system has experienced a functional regression since upgrading from Mint 19.3 (based on Ubuntu 18.04) to Mint 20 (based on Ubuntu 20.04). After investigation, I believe that the problem is caused by commit d1eaf72c.
The system layout features a /srv
directory, under which are two empty directories mounted to BtrFS subvolumes. The root mount, which contains /srv
, is also a subvolume on the same partition.
The contents of the volumes mounted under /srv
are primarily media and documents shared among users, or that are not appropriate for /home
, which is a separate subvolume and managed independently. Use of /srv
for such content is largely, though perhaps imperfectly, consistent with the File Hierarchy Standard, and also makes it an appropriate location for trash management.
The subvolumes contain directories named .Trash
, and that otherwise follow the requirements of the FreeDesktop Trash Specification.
Problem
Before the upgrade, I had no problem trashing files in locations under /srv
.
Now GIO generates the following message, the same as in d1eaf72c:
gio: file:///srv/usr/foo: Trashing on system internal mounts is not supported
Remarks
Effectively, GIO is deciding for me, or more precisely, against me, that certain volumes are not suitable for trash management, whereas, based on the nature of their contents, they seem perfectly suitable for such.
The functional distinction introduced by d1eaf72c is determined by g_unix_mount_is_system_internal()
, which is documented, in part, as follows:
This is the Boolean OR of
g_unix_is_system_fs_type()
,g_unix_is_system_device_path()
andg_unix_is_mount_path_system_internal()
onmount_entry
’s properties.The definition of what a ‘system’ mount entry is may change over time as new file system types and device paths are ignored.
Also note that file managers using GIO still find content previously trashed on the same volumes for which they will no longer trash new content. This conflations strikes me as confusing and likely to lead to new problems.
Resolution
Essentially, it seems that GIO needs a way to distinguish between volumes that it would exclude categorically from trash management, and to do so, is using some existing function, with limited clarity about its purpose or design. Ultimately, the distinctions in the current logic may be too narrow or rigid to support a usable system of trash management.
Further, as I understand, GIO will use a .Trash
directory if one exists, otherwise create one, except in the case of excluded volumes, for which it will ignore any existing .Trash
directory and will not create one. Perhaps a third category of volumes is appropriate, in which GIO would use any existing .Trash
directory, but would not create one.
Overall, it may be necessary that hard-coded distinctions give way to other, more flexible means of selecting directories for exclusion from trash management, such as whitelists or blacklists, given within a volume, of its directories.
Perhaps an appropriate stopgap solution is reverting d1eaf72c. Although I lack the context, its purpose is unclear. The comments suggest that the main benefit, or among the larger benefits, is resolving network issues, but issues relating to shared mounts may be best left to logic related directly to that particular distinction.
See also
This issue may be related to #1885, but is not a duplicate.