tohle chceš potkat večer u popelnic 🗑️🕷️

#trashbin #huge #spider #prague #czechia #photo

Baltimore, MD -July 2025.

#trashBin #alley #graffiti #photography #photoWalk

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:

This 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 test directory is made by the current user (assume that the current user is aptivi)
• The root directory inside the user-owned test directory is made by aptivi
• A file, file, which aptivi owned, was created inside the root directory
• The root directory’s owner had changed to the root user
• The test directory can be moved to aptivi‘s trash, since the first chained rule has been followed
  • Explanation: test was owned by aptivi and had a parent directory that was also owned by aptivi
• The root directory can’t be deleted from aptivi‘s trash, since the second chained rule has been followed
  • Explanation: root, a non-empty directory owned by root, was inside test, owned by aptivi, and the root directory can’t be removed
• The root directory can now be found underneath the expunged folder under aptivi‘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