So, I get a popup saying my system drive is nearly full. (Understandable; it's this 256 GB SSD drive about the size of half a business card.)

I run FileLight and find there's a log file taking up about 95 GB -- so I delete that.

Still 0 GB.

I try emptying the Trash folder, but... apparently that isn't a thing when you're running Caja (MATE flle manager) under KDE. There is no right-click option to empty it.

I run FileLight again and find where the Trash folder is located. I go there and use CLI (well, okay, a Caja action I set up which uses rm) to delete the file from Trash.

Still 0 GB... though FileLight now says I'm only actually using up about half the drivespace, 123 GB. Both df and Caja say no space free, even though the 95 GB file is no longer in evidence.

I had to reboot before the free space would finally show up. This seems like maybe a design flaw in the filesystem API? Like, apparently a block of space can remain allocated for the remainder of a session even when the file attached to it has been deleted.

· · Web · 2 · 0 · 0

@woozle It might’ve been whatever program that produced the log file was still holding the file handle open. Linux will let you delete a file that’s still in use but it can’t actually deallocate it until all handles have been closed.

@foxwitch I think that's what was happening, and why the reboot was needed -- but I do feel like that's an API design issue: it shouldn't be possible to maintain an allocation of disk space without there being a corresponding file entry somewhere.

@woozle I believe the lsof command would’ve still shown the file open along with the corresponding PID of the program still using the file. File system specific debug tools should also show the deleted file’s inode as still allocated but no longer associated with the file name since file was deleted but the resources can’t be released until the program stops using them or is forced to quit. An alternative would work like Windows where a file is unable to be deleted while in use.

@foxwitch I suppose another solution would be for FileLight (et al.) to also check lsof when reporting usage.

I think if I was designing the system, I'd move the to-be-deleted file into a special folder, which would then normally be checked by file-allocation-mappers (like FL) without any extra coding.

@woozle Before you use a delete feature in a file manager, make sure you understand how it handles "trash". A quick google search suggests it creates a ".Trash-999' folder or something similar. Your best bet is to use the command line to find the .Trash-999 folder and delete it.

@woozle Ah, never mind - I didn't read carefully enough to see that you had already figured out a way to deal with it.

But anyway, it is indeed possible for freed up space to not be immediately available, especially depending on what file system is being used.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!