#55 lbreakout2.hscr gets deleted if /var is full

closed-fixed
nobody
None
5
2010-10-05
2010-02-14
Colin Tuckley
No

Forwarded bug from Debian

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=246589

Sometimes my /var partition fills up when I don't run apt-get autoclean
often enough. When it is full and I play lbreakout2, the lbreakout2.hscr
file in /var/games gets truncated to 0 length.

Rather than overwriting the highscore file, I think it should move it out of
the way, right the new one, then delete the old one. If writing the new
one fails, it could move the current one back.

Discussion

  • Michael Speck
    Michael Speck
    2010-10-05

    • status: open --> closed-fixed
     
  • Michael Speck
    Michael Speck
    2010-10-05

    Hm, this is a rather old bug report (version 2.4.1 in 2004?). I tried to reproduce it but it works here. Maybe it has been fixed along the way but I could not find when and by whom. I created small loopback FS, filled it up with garbage data and the highscores were not truncated on save but kept (since fopen uses r+). I fixed the alternative fopen call (if data NOT stored in HIDIR but config dir) which theoretically could produce truncating of file to 0 on write error in revision [10]. But the bug report does not seem to stumbled across this. So again I think this is fixed already. One very minor issue remains though: New charts are prepended to list so data never reduces only increases thus using r+ as a fix and just write is basically okay. If data of existing charts changes though (names differ in length) and no more space is left, the last chart written may be truncated and some entries be lost (as well as all other charts that have no space to be written). Theoretically. In reality it seems all partial write calls are not performed when no space left for all the calls, leaving the initially loaded charts intact. So all this is not even worth this long comment, just a bad habit of mine. :-)