GNOME fixes the Trash bug from 2009!
GNOME Desktop had a bug in the Trash function where the leftover files from the user-wide expunged trash directory, found in ~/.local/share/Trash/expunged, were not being deleted properly, and that the Nautilus file manager, which GNOME uses, inaccurately reported that the trash was empty. This bug was originally reported in Ubuntu’s Launchpad under the title of “Emptying the trash can lead to have files still on disk in expunged.”
This caused problems with the free disk space, since the bug reporter had stated that they had about 70 GB of files in the expunged directory, which were handled incorrectly when emptying the trash. Furthermore, said directory was found in the hidden .local folder underneath your home directory, which was not obvious to the average user. This was said to be due to wrong permissions being applied to the offending files, and a reproducer was found:
mkdir -p test/roottouch test/root/filesudo chown root:root test/rootThis followed the two chained rules, first for trashing and second for emptying, where, ipsis verbis:
- when a directory A is in a directory owned by you and it’s owned by you, you can obviously move it.
- when a directory B is in a directory A owned by you but you don’t own it, and it’s not empty, you can’t delete it.
So, essentially, this boils down to:
- The
testdirectory is made by the current user (assume that the current user isaptivi) - The
rootdirectory inside the user-ownedtestdirectory is made byaptivi - A file,
file, whichaptiviowned, was created inside therootdirectory - The
rootdirectory’s owner had changed to therootuser - The
testdirectory can be moved toaptivi‘s trash, since the first chained rule has been followed- Explanation:
testwas owned byaptiviand had a parent directory that was also owned byaptivi
- Explanation:
- The
rootdirectory can’t be deleted fromaptivi‘s trash, since the second chained rule has been followed- Explanation:
root, a non-empty directory owned byroot, was insidetest, owned byaptivi, and therootdirectory can’t be removed
- Explanation:
- The
rootdirectory can now be found underneath theexpungedfolder underaptivi‘s .local folder
The appropriate GNOME bug tracker ticket was brought to the upstream developers six years ago from writing who confirmed that the issue was happening. According to this blog post, the merge request was submitted to the GNOME project, which was approved. The fix is now at the upstream GLib code.
An internal function was added to the I/O part of the GLib library, called check_removing_recursively(), that checked whether “subsequently deleting the original file from the trash (in the gvfsd-trash process) will succeed.” It also checked the ownership of the files before deletion and automatically assigned the file mode (chmod) to allow deletion.
That filled one of the TODO tasks in the I/O code that handled emptying the trash in the internal function, g_local_file_trash(). It said “Maybe we should verify that you can delete the file from the trash before moving it? OTOH, that is hard, as it needs a recursive scan.”
Now, you can empty the trash without worrying about the free disk space, but only if your Linux distribution uses a version of GNOME that contains this fix. We expect that this fix will land to several distributions in the coming days or weeks.
Pro tip: to eliminate the remaining expunged files after installing the fixed version of GNOME, use this trick to free up disk space.
#GNOME #GNOMEDesktop #Linux #LinuxDesktop #news #Tech #Technology #Trash #TrashBin #update
