It's worth clarifying the effect of deletion and uninstalling in order to realise that the deletion of files, as well as the uninstallation of packages, can both create space in the filesystem, and that the space created through both approaches then becomes available for the user to use for the creation of other files, or other installed packages.
In the case of uninstalling packages, it's clear that the space on the filesystem will become available to the user since that's what the package manager does, and in the case of removal of packages with apt, it will inform the user on screen of how much space will become available again.
In the case of the removal of files, space will also be created for the user to use for use either for the further writing of files or for the installation of packages.
In this example, the file of kernel 6.7 source code was downloaded from kernel.org and the command: df -h, was used to output the size of the available space on the filesystem to show that the deletion of files (by the rm command) makes space available for the user.
Before downloading the kernel 6.7 compressed file, there is 406G available on this filesystem:
Code:
[tom@min ~] df -h
Filesystem Size Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3 443G 15G 406G 4% /
<snip>
Once the kernel has been downloaded and decompressed, it takes up around 1.5G of space:
Code:
[tom@min ~/src/kernel]$ du -sh linux-6.7
1.5G linux-6.7
The output of the df command now shows that the available space on the filesystem has been reduced to 404G:
Code:
[tom@min ~] df -h
Filesystem Size Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3 443G 17G 404G 4% /
<snip>
Upon deletion of the kernel and all the files and directories it created upon it's decompression, the available space on the filesystem has returned to 406G
Code:
[tom@min ~] df -h
Filesystem Size Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3 443G 15G 406G 4% /
<snip>
It's clear that the deletion of files creates space on the filesystem.
In relation to the assertion: "Until the area where the file(s) reside have been over written they are still available to be accessed.", this is the case, but it's immaterial in relation to size of the space made available to the user after the deletion of the files. That space, despite the old data still on the disk, nevertheless becomes available for the user to use. The fact that the data still sits on the disk until overwritten by the operating system is a function of the way in which files are removed, which is by having their metadata removed or neutralised so that the filesystem no longer sees the files since it needs the metadata to refer to and identify those files. Since this is the way in which removal of files happens, (by neutralising the metadata) the actual data of the files stays in place. Because that's the case, it's possible with specialised tools to access file data even without the metadata being the guide, so long as that data hasn't been overwritten. But if new files are written by the user, that space with the old data, is available for the user as space, as shown in the above example. It's not the case that such space with old data is not counted as space available for the filesystem to use.
The upshot is that, the removal of large files creates space, so identifying such files and assessing whether they can usefully be removed, can be useful in situations where there are problems with space.
