trash requirements restrictive and inconsistent for non-system mounts
Background
The FreeDesktop.org Trash specification explains where compliant applications should look when attempting to resolve the trash location for a particular store. Specific, restrictive ownership and permissions requirements are described, with the suggestion that these requirements may be relaxed for stores that lack a full POSIX permissions scheme. However, no further details are offered on this issue.
In a specific common use case, a user will attach removable media to a system.
In such cases, any or several of the following are highly likely to apply:
- The file system is not a Linux type.
- The UID layout for the file system does not concord with that of the host system.
- The file system is mounted such that all files appear with a particular owner, group, and permissions set, for example, root.root and 0666/0777.
Any of the above conditions alone is sufficient for particular requirements given in the specification to become too restrictive for practical use.
This reality is reflected in part by the current behavior of GIO, which searches locations with a less restrictive permissions set when listing current trash contents. However, this practical, relaxed interpretation does not carry into the case of moving items to trash.
Message boards on this subject currently offer suggestions for mounting an NTFS volume as a particular user (e.g. 1000) on the host system, to work around the above restrictions. Such approaches are inconvenient and carry significant side effects. One prominent side effect is lack of support for multiple users on the host system using the same removable media, a case sadly overlooked by many Linux desktop distributions.
Suggestion
Relax some or all of the following requirements, and perhaps others relevant but not listed, for trash locations for certain mounted volumes:
- Trash location is user owned.
- Trash location has sticky bit set.
Further Notes
-
Currently, when finding a trash location fails, a non-specific message is produced, making it impossible to determine the changes needed in the volume to resolve the issue. This problem is already separately documented in #1283 (closed). The current issue is related but not a duplicate.
-
GIO-based file shares ought also to be considered when addressing this issue. For example, GNOME-family file managers currently behave differently with respect to trash management for the same network share, depending on whether the share is accessed as a NFS system mount or GIO SMB share, with the behavior in the former case being more friendly to the user. Users expect that the application interact with the same storage device uniformly, with artifacts of the particular access method creating minimal degradation of the experience.