Debian Bug report logs - #246589
lbreakout2: lbreakout2.hscr gets deleted if /var is full

version graph

Package: lbreakout2; Maintainer for lbreakout2 is Colin Tuckley <colint@debian.org>; Source for lbreakout2 is src:lbreakout2.

Reported by: Josh Metzler <joshdeb@metzlers.org>

Date: Thu, 29 Apr 2004 19:33:06 UTC

Severity: normal

Found in version 2.4.1-3

Done: Colin Tuckley <colint@debian.org>

Bug is archived. No further changes may be made.

Forwarded to https://sourceforge.net/tracker/?func=detail&aid=2951690&group_id=9301&atid=109301

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daniel Burrows <dburrows@debian.org>:
Bug#246589; Package lbreakout2. Full text and rfc822 format available.

Acknowledgement sent to Josh Metzler <joshdeb@metzlers.org>:
New Bug report received and forwarded. Copy sent to Daniel Burrows <dburrows@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Josh Metzler <joshdeb@metzlers.org>
To: submit@bugs.debian.org
Subject: lbreakout2: lbreakout2.hscr gets deleted if /var is full
Date: Thu, 29 Apr 2004 15:29:04 -0400
Package: lbreakout2
Version: 2.4.1-3

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.

Josh



Set Bug forwarded-to-address to 'https://sourceforge.net/tracker/?func=detail&aid=2951690&group_id=9301&atid=109301'. Request was from Colin Tuckley <colin@tuckley.org> to control@bugs.debian.org. (Sun, 14 Feb 2010 21:18:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Colin Tuckley <colint@debian.org>:
Bug#246589; Package lbreakout2. (Tue, 05 Oct 2010 09:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Speck <speck.michael@gmail.com>:
Extra info received and forwarded to list. Copy sent to Colin Tuckley <colint@debian.org>. (Tue, 05 Oct 2010 09:51:03 GMT) Full text and rfc822 format available.

Message #12 received at 246589@bugs.debian.org (full text, mbox):

From: Michael Speck <speck.michael@gmail.com>
To: 246589@bugs.debian.org
Subject: Fixed
Date: Tue, 5 Oct 2010 11:49:40 +0200
Is very old and seems to fixed along the way already. See comment at SF bug.

Regards,
Michael Speck




Reply sent to Colin Tuckley <colint@debian.org>:
You have taken responsibility. (Tue, 05 Oct 2010 10:21:05 GMT) Full text and rfc822 format available.

Notification sent to Josh Metzler <joshdeb@metzlers.org>:
Bug acknowledged by developer. (Tue, 05 Oct 2010 10:21:05 GMT) Full text and rfc822 format available.

Message #17 received at 246589-done@bugs.debian.org (full text, mbox):

From: Colin Tuckley <colint@debian.org>
To: 246589-done@bugs.debian.org
Subject: Unreproducable upstream - closing
Date: Tue, 05 Oct 2010 11:11:33 +0100
Upstream believes the bug to be unreproducable - so closing.

Comment By: Michael Speck (kulkanie)
Date: 2010-10-05 09:48
Message:
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. :-)




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 03 Nov 2010 07:31:42 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 07:22:34 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.