My Portage world file seems to have been emptied sometime during the last few weeks. It currently only contains names of a few recently emerged packages. Specifics of my system: - I run /var as a separate partition (4GB) - Some time ago I got an error from 'emerge -vpuDN world' which turned out to be due to /var having filled up (My /var/log/messages file had grown to over 3GB, due to excessive amounts of logging from a kernel module) From this I guess the problem is related to how the world file is updated: that maybe this is done in a way that may fail if eg. the partition is full. I've seen some comments attached to other bugs that hint to similar problems; nobody have been able to pin point the exact conditions under which this is happening, though. Reproducible: Didn't try Steps to Reproduce: 1. Fill /var partition 2. Try to run an emerge Expected Results: Emerge should fail early if the world file can not be updated safely for some reason.
writedict calls lack any form of error checking... I'm inclined to just have them throw an exception when failures occur. This immediately makes any failing code puke instead of silently swallowing it. Also deviates from the grab/write norms though. Thoughts?
writedict() swallows the exception when it can't open the file for writing, but it has nothing after that. It would seem that there's no way to know that the write has failed...
So... throw the exception, imo. We add in an optional swallow_exceptions=False, sed the existing code to set it to true ('cept where we need to have it puke), then gradually ween the code away from swallow_exceptions=True Thoughts?
My point is that the only time an exception is raised is when it fails to open the file. If the open fails, no data will be lost. What seems to be happening is that the file is opened successfully (and truncated), data is written into the buffer and then the file is closed yet the close fails without any exception being raised.
write to a tmp file, mv it into place via a rename... nice way to handle atomicity issues also.
fixed in svn.
*** Bug 128362 has been marked as a duplicate of this bug. ***