I was getting warnings about limited free disk space from (df) disk free (93g used out of 100g) in root (/) but (du) disk usage showed only 20% disk usage. This was after I had just increased root (/) partition from 40G to 100g based upon df warnings.
Further investigation showed large image files that I had deleted were still on the disk in /var/.Trash-0. There were two 35g images I had been experimenting with on virtual machines and later deleted. Their filesnames included word (deleted). Furthermore I found more deleted files still on disk in /opt/.Trash-0. Again, I found more deleted but not removed from disk files in /home/.Trash-0.
I manuallly deleted all these files as root and my df and du lines up at about 20% disk usage.
I think many people have enlarged root partitions and maybe even changed out disk drives based upon erroneous data from df warnings not knowing that supposedly deleted files were still on their disks.
Why aren’t files deleted from these directories really deleted from the disk? Why doesn’t these desktop trash empty process remove these? The previous may be a permissions problem if the files are ownedby root but why isn’t there any notification that these files are hung up somewhere in the system and maybe root has to take care of them.
using btrfs files system on root directory
I use bleachbit disk cleaner as root and that program never deleted them either.
This seems like a basic flaw in OpenSUSE. I would think there should be a root process to clear this disk space for all the .Trash-0 directories rather than lead people astray to make other solutions.
Comments anyone?
Tom Kosvic
Normally, that is because the file is still being used (accessed).
Deleting a file just deletes the directory entry. The disk space is freed when
(a) there are no directory entries, and
(b) there is no process which has an open file descriptor for that file.
If you have deleted a large file, but it is still taking up disk space, then you need to find the process that is using this file, and kill that process. The easy way is to reboot.
Hi
That would be the function of the GUI file manager in use and running as root user… turn off the creation/use of the trash folder, in your case for super user/root. I would suggest running the likes of any virtual machine images on a separate xfs partition and use the vm tools for backups rather than btrfs and the likes of snapper?
With reference to the comments above, as I recall the things that were done, I am sure that the deleted/non-deleted image files survived several reboots. Even before I found the undeleted image files, I am sure that there was no process that was running and using these files. I looked to see what was running in my investigation into VM apppllications to see what was inplay and running. That is unless the process had some obtuse name.
The image files were in a /home/user/VMimage directory. I used a VM image manager gui to pull them in for test in several VM processes including gnome-boxes. When I couldln’t get them going, they were deleted through the VM manager gui from the VM application. Later I then deleted the original files from the /home/VMimage directory.
I think the hung deletions were most likely those deleted from the VM manager process. I tried several so I can’t say which one. Per suggestions above, I would recommend that the deletion actions of the VM manager guis be reviewed.
BUT, I am also still wondering why there is no way of knowing these files would be still on your disk and occupying significant disk space except for blind luck.
Hi
The only application that I’m aware of that creates a .Trash is a GUI based file manager?