Full disk destroying my softwasre - any way to prevent that?

[-SPM-Mad]

Since I have quite limited diskspace, it happened two times already that I did not notice my drive being filled to the brim.
One time it was a KDE bug, causing the trash to not empty. I had over 6GB of data in my 'empty' trashbin. Anyways...

Both times my system reacted in a rather bad way: All sort of things suddenly fail. Manpages are not displayable, Windows cannot be opened and such.
But the worst thing is that several files got corrupted or removed. The first time I was running VirtualBox, and those configs got lost. Last time I was using Opera and closing it, causing it now to be set back to default preferences.

Okey, if really zero bytes were avilable, then the new files like the session cannot be saved if they are bigger. But if not, why do these files dissapear? Why do the programm not show me an error? These programms are defenatly not coded so that they first empty the file before saving the new data. Such a problem is under Windows very uncommon.

One thing I could do is a cronjob checking my drivespace. But still... I do not understand why several config files of running programms get lost if the drive gets full (and the programms do not notice even)
Are there any modifications I can do to my (ext3) filesystem or kernel to prevent such problems?

Greetings
-SPM-Mad

[frostschutz]

Well, to write a new config file, the old one is overwritten. To overwrite an old file, the old file has to be deleted. If it fails to write the new file because the disk is full even after deleting the old file (which can happen easily if there is something else trying to write files at the same time or just because the new file is bigger than the old), then the new file won't be written but the old file deleted. You have the same issue in Windows or with any file system and any app that over-writes files this way. Of course any app that needs to create temporary files in order to work but can't (for example manpages are compressed and may be uncompressed as you are reading them) it will fail too.

If you're really that tight on hard disk space you should consider buying yourself a bigger disk. Or if it's just a matter of distributing the available space, resize your partitions.
Or just delete stuff. There are some apps like xdiskusage that can show you very detailed which files or folders on your hard disk are space wasters.

Running out of hard disk space is something you just don't want to do.

[-SPM-Mad]

But I wonder why I never experienced such problems with other systems.

A solution which would lessen the problem is that if I copy a 10MiB file and only have 8MiB left, it should _NOT_ copy 8MiB and then fail, but warn be before copying the file.

So where would I have to suggest this? KDE/Gnome? ext3 developers? Kernel Mailinglist?

And/Or is there any better way than a cronjob running every x-seconds to check how much space is left to help me print out a warning?

Greetings
-SPM-Mad

[frostschutz]

The problem is, you don't always know that you're going to write 10MB when you do. The filesystem (thus kernel) sees you creating the file, and writing to it, how large it will be, no one knows.

A smart copy software, like some KDE front end, could do that kind of calculation for you, except for the fact that it's a bit expensive to check all eventualities and in the end, only the filesystem itself knows when it can't write any more data. Such a system would be a pain to implement, and useless in most cases. It'd definitely not be done for simple tasks like writing config files, providing enough hard disk storage space for an application to run is your responsibility.

There is very little chance that anyone would take you up on your suggestion, because it's just not done that way; it's usually easier to just provide enough storage space to begin with.

[-SPM-Mad]

Well, that makes score for windows

Honestly, I am quite allergic to data-loss =/

Oh well, lets see what workaround I can find for this.

[cwr]

There's no way any OS can tell how large a file you are copying; the file may
be coming across a pipe (eg: tar cf - . | (cd newdir ; tar xf -)) and no-one
has yet written a telepathic OS.

However, at least some, and I think most, filesystems can be set to keep
something in reserve for use by root when things go wrong; check the
ext filesystem manpages, and see if setting more space aside (when the
filesystem is built) might help you. That should prevent most data
corruption.

Will

[-SPM-Mad]

Ofcourse not.

But direct file-copies as done by (s)cp, mv and desktop-manager tools (KDE filecopy dialoge) can check the filesize and free space. That should be something really trivial to add. And which user wants to copy a file knowing it will not fit? So hardly anyone would be upset about such a check.

Greetings
-SPM-Mad

[cwr]

Again it may not be that easy; mv on a single filesystem may just be a rename,
but it could call cp under the covers if moving between filesystems, and then at
one point you need space for twice the actual file size.

The best bet is just to use the semi-standard approach of reserving blocks for
use by the super-user if or when things come unstuck, so that cleaning up
shouldn't be too much of a problem.

Will

[frostschutz]

cp and mv already have checks where necessary... cp refuses to copy if source == target, and mv does not delete source files when the target file could not be written. Checking wether there is enough disk space for an operation, is not possible. Especially not for complex operation on whole directory trees instead of just one file. Such a check would be prone to return the wrong result (after all if something else writes on the disk the result of the check is not relevant anymore). What you would have to do for a reliable check is preallocate disk space and then in-place overwrite the preallocated space, and this again can lead to deadlocks (two processes trying to allocate space and both failing to do so, when one alone could succeed). It's not been done because it can't be done right.