Launchpad has imported 33 comments from the remote bug at https://bugs.gnucash.org/show_bug.cgi?id=105669.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2003-02-09T19:45:56+00:00 Monniaux-e wrote: Saving when the partition on which the file is is full - does not save the file - yet does not show any error or warning message. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/0 ------------------------------------------------------------------------ On 2003-06-15T02:00:30+00:00 Warlord-a wrote: *** Bug 115205 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/1 ------------------------------------------------------------------------ On 2003-11-05T17:21:27+00:00 Bugzilla-gnome wrote: *** Bug 126269 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/2 ------------------------------------------------------------------------ On 2004-11-01T09:38:11+00:00 Christian Stimming wrote: *** This bug has been marked as a duplicate of 110606 *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/3 ------------------------------------------------------------------------ On 2006-08-11T16:09:00+00:00 Chris-shoemaker wrote: JohnFlux reported on IRC that this still happened in 2.0. He thinks there was a dialog error, but the file was blanked out. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/4 ------------------------------------------------------------------------ On 2006-10-09T06:40:34+00:00 Orgad Shaneh wrote: (In reply to comment #4) > JohnFlux reported on IRC that this still happened in 2.0. He thinks there > was > a dialog error, but the file was blanked out. > I had the same problem. I don't recall any dialog error, but I ended up with an empty file (had to recover from backups!) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/5 ------------------------------------------------------------------------ On 2007-01-15T12:36:39+00:00 Christian Stimming wrote: *** Bug 396683 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/6 ------------------------------------------------------------------------ On 2008-07-11T18:56:04+00:00 Bugzilla-gnome-org wrote: still a problem? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/7 ------------------------------------------------------------------------ On 2008-09-12T14:03:52+00:00 andi5 wrote: (In reply to comment #7) > still a problem? Yes, I think so. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/8 ------------------------------------------------------------------------ On 2008-09-12T14:07:37+00:00 andi5 wrote: Created attachment 118586 First sketch of a patch A first version of a possible solution to this. It adds checks after each write operation, so that a full disk is not only detected but also further writes minimized. Please note that this patch has been produced rather quickly and survived only two tests. It really needs a severe review and testing. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/9 ------------------------------------------------------------------------ On 2008-11-03T11:00:22+00:00 Christian Stimming wrote: *** Bug 503084 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/10 ------------------------------------------------------------------------ On 2008-11-05T19:09:29+00:00 Grant Bowman wrote: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/12 ------------------------------------------------------------------------ On 2008-11-08T03:15:13+00:00 Saivann Carignan wrote: Andreas Köhler : I applied your patches to gnucash 2.2.6 source code and I was still able to reproduce the bug. I also have to mention that when reproducing the bug, the gnucash file content is completely blanked out. Gnucash shows no error message while saving, but it fails to load the file when you restart it because the file is now completely empty (0 byte). Easy steps to reproduce : 1. Save a copy of your gnucash file on a small partition (USB key?). 2. Open your gnucash file with gnucash. 3. While gnucash is open, open a terminal on the same folder where the gnucash file is stored, and launch this to take all available space left : dd if=/dev/zero of=file 4. Go back to gnucash, change something in your accounts, and click on the floppy disk icon to save. Result : The gnucash account file is now empty, gnucash didn't show any error message and you won't be able to recover anything if you close gnucash. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/14 ------------------------------------------------------------------------ On 2008-11-08T14:59:32+00:00 andi5 wrote: I cannot reproduce that with none of trunk or 2.2.6 with my patch applied, whether (1) opening file, filling all space left (2) filling all space left, opening file (3) filling enough space for a second file save to fail There is always a warning shown, either that the backup file could not be created or the file not written. The original file is never touched. I tried with compression on and off. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/15 ------------------------------------------------------------------------ On 2008-11-08T23:51:49+00:00 Saivann Carignan wrote: I just tried with 2.2.7 as well with your patch from comment #9 applied (and all hunks applied correctly before a I built gnucash) and I'm still able to reproduce the bug. The only thing that seems different when I compare to your steps is that you fill all space before opening gnucash. In my case, gnucash opens while there is still available space, I fill the partition *after* launching gnucash. However, I just tried to fill the partition *before* opening gnucash, and the bug still appears. Here's a screencast that definitively demonstrate that the bug is still reproducible and all the steps that I described. http://upload.leservicetechnique.com/bugs/gnucash_nospace_data_corruption.ogv Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/16 ------------------------------------------------------------------------ On 2008-11-09T13:30:51+00:00 andi5 wrote: Hm, I see your screencast and I could provide my own as well, showing you that the patch works fine for me. Previously, I loopback-mounted a small xfs file system from a file, now I used my fat32 formatted USB stick, preparing it with an 800 MB file. I do not really understand why we are seeing different results... BTW, with (1) in comment 13 I meant that I first opened the file (either by loading on start or loading after start) and then used the dd command the same way you did. The data file I used is 2 MB of size. I am sorry, but are you sure that the version you are running is still patched, maybe some pbuilder magic is playing tricks on us :-) Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/17 ------------------------------------------------------------------------ On 2008-11-09T17:47:44+00:00 Saivann Carignan wrote: Mmh, I thought that the screencast might have been a starting point to see what is the difference between our steps to reproduce. Can the partition size have an impact on this bug? The hypothesis that I don't use a patched gnucash sounds impossible here because I did take care to apply the patch directly to the source tarball, so pbuilder wouldn't be able to reverse this in any way. I also removed current intalled gnucash and then installed my patched one, and gnucash clearly shows that it has been built today when starting. Of course, I might be wrong :-) , but I'm still pretty convinced that I did it well there. Don't hesitate to ask me more testing. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/18 ------------------------------------------------------------------------ On 2008-12-01T22:01:49+00:00 andi5 wrote: Hm, honestly, I am not sure what to ask :-) May you retest the following: Create a 20mb file from /dev/zero, create an xfs on it, loop-back mount it, repeat the steps depicted? That should really equal what i have done! Maybe someone from the cc list can give us more insight here. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/19 ------------------------------------------------------------------------ On 2008-12-04T06:16:23+00:00 Saivann Carignan wrote: Andreas Köhler : I might have found where the bug still happens and where it is fixed! I created a 20Mb file, formatted as xfs and loop-mounted. Inside of this loop-mounted partition, I put my gnucash file size: 341953, I open gnucash, I take all available space with dd if=/dev/zero of=./file and I try to save with gnucash. I noticed that with xfs, there is always 20kb of space left even after filling the partition. Now I got a different result compared to the last time. gnucash now takes about 3 minutes to save the file instead of 2 seconds. No error message appears, and the gnucash file is finally destroyed (0 or 30 Kbytes) at the end of the ~3 minutes. It prints this in terminal : Error: xaccOpenLog(): cannot open journal 28 No space left on device However, here's the interesting part : All of this has been tested on a 20 Mb partition where I only put a single gnucash file (there is no .log or .xac files). If I open gnucash, save and close, one .log file appears. Then at this point, if I fill the partition, open gnucash and click on "save", the bug doesn't happen! Gnucash shows a error and refuses to save and let me choose where to save the gnucash file. So far, in my case, the bug can still be reproduced unless there is a .log file in the same directory then the main gnucash file. I hope it helps, thanks for working on this! Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/20 ------------------------------------------------------------------------ On 2008-12-04T06:18:51+00:00 Saivann Carignan wrote: So far, in my case, the bug can still be reproduced unless there is a .log file in the same directory *than* the main gnucash file. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/21 ------------------------------------------------------------------------ On 2009-01-01T14:50:07+00:00 betozamo wrote: I haven't checked in the Linux version, but in the windows version (up to the last one, 2.2.8), I have the same problem... I use a Truecrypt partition file of 2Mb just for the Gnucash files, which I carry around on my cell phone, so I can copy this partition file in my home laptop or my office PC. Whenever the partition file is full, the next save seems to be ok but it is corrupted and blanked to zero most of the times. This really bothers me, because I only realize it when I open GnuCash again and usually I don't remember all my last transactions. Please fix it ASAP. Regards Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/22 ------------------------------------------------------------------------ On 2009-06-09T22:14:24+00:00 Phil-longstaff-r wrote: Changed to "XML Backend" Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/23 ------------------------------------------------------------------------ On 2009-10-16T19:37:09+00:00 Christian Stimming wrote: Just in case I need the instructions for creating a small partition again: # Create directory for mount point mkdir tmpmnt # Create 20MB file (cannot be smaller) dd if=/dev/zero of=./file bs=1M count=20 # Format this as XFS file system sudo mkfs -t xfs ./file # Mount this as loopback filesystem sudo mount -o loop ./file tmpmnt Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/24 ------------------------------------------------------------------------ On 2010-01-31T18:46:36+00:00 andi5 wrote: I have committed the attachment as r18593 to ease testing. @Beto: May you please test on Windows from a nightly build (http://code.gnucash.org/builds/win32/trunk/) that includes that change? I still cannot reproduce the bug, Saïvann :( Christian described in comment 22 how to set up an empty loop-back mounted xfs file system. May you continue in the same manner how to to reproduce the bug? I mean, whenever you do something (open gnucash, change something in the register, save), give us the output of ls -li and whether gnucash printed anything to the terminal you started it from. Please use the current trunk (2.3.8+). Regarding the log files, GnuCash always creates those files whenever I open a file, so there is one. Maybe it should always be non-empty (it is not), but the existence of log files does not seem to influence GnuCash's behavior here wrt saving files. Let us trash this bug this time. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/25 ------------------------------------------------------------------------ On 2010-02-01T07:06:33+00:00 Saivann Carignan wrote: I'm sorry to confirm again that latest trunk still react exactly the same as I described in my previous comment, I tested build r18596. I followed exactly the steps of christian Stimming to create the loop- mounted partition. Gnucash fails and bring its own file to 0Kb with these steps : # Create directory for mount point mkdir tmpmnt # Create 20MB file (cannot be smaller) dd if=/dev/zero of=./file bs=1M count=20 # Format this as XFS file system sudo mkfs -t xfs ./file # Mount this as loopback filesystem sudo mount -o loop ./file tmpmnt # Copy a existing gnucash file it the tmpmnt directory (mine is 547kb) # Open that file with gnucash # Fill the partition with a big file dd if=/dev/zero of=./tmpmnt/file # Click the floppy disk icon to save in gnucash. However, as said previously, if you close gnucash, and reopen it before you fill the partition, it won't hit the bug and it will show a message to say that it's not possible to save the file. Gnucash successfully prevent the bug with these steps : # Create directory for mount point mkdir tmpmnt # Create 20MB file (cannot be smaller) dd if=/dev/zero of=./file bs=1M count=20 # Format this as XFS file system sudo mkfs -t xfs ./file # Mount this as loopback filesystem sudo mount -o loop ./file tmpmnt # Copy a existing gnucash file it the tmpmnt directory (mine is 547kb) # Open that file with gnucash # Click the floppy disk icon to save in gnucash. # Close gnucash. # Open gnucash (with the same file). # Fill the partition with a big file dd if=/dev/zero of=./tmpmnt/file # Click the floppy disk icon to save in gnucash. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/26 ------------------------------------------------------------------------ On 2010-02-01T07:10:53+00:00 Saivann Carignan wrote: If forgot to mention that all I get in terminal when reproducing the bug with --debug is this : Ceci est une version de développement. Elle peut ne pas fonctionner correctement. Rapporter les anomalies ou tout autre problème à [email protected]. Vous pouvez consulter ou transmettre des rapports d'anomalie sur http://bugzilla.gnome.org La dernière version stable était GnuCash 2.2.9 La prochaine version stable sera GnuCash 2.4 Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/27 ------------------------------------------------------------------------ On 2010-02-01T09:17:31+00:00 andi5 wrote: Thanks for retrying :) (1) You do not need to change something to save the file, i.e. after opening it it is already dirty? Can you provide such a test file, maybe by adding non-basic stuff to an empty file. If not, you might want to send it to me privately, encrypted with gpg. (2) What about ls -li between those steps? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/28 ------------------------------------------------------------------------ On 2010-02-01T10:12:05+00:00 Saivann Carignan wrote: 1- The file I used contains all my account. You're right, I have to change something, otherwise the "Save" button is greyed out. So far, adding or deleting a transaction in any account is enough to let me click on "Save", and the bug does not seem to depend on what changes I made in the file with gnucash. I tried to create a new file, with the new account wizard, and to test if the bug was reproducible with it and I reproduced the bug again. Therefore I don't need to send you any file that contains sensitive data, a new gnucash file seems to be enough to reproduce the bug. I attach a gnucash file to the bug report, created today with gnucash wizard. I was able to reproduce the bug with that file. After saving with gnucash, the gnucash file size drop to 0Kb, and after that if I close gnucash and open it again, it complains : "Le type du fichier /media/X/System/local/zxz/tmpmnt/test est inconnu." I also tried to leave a bit more space left than 20kb and the result was surprising, instead of having his size dropped to 0kb, the size dropped from 500kb to 200kb. Therefore it looks like gnucash is writing his log files until there is no space left, after what it starts to eat his own main file to get space for the log files. Ugh, strangely, while I was able to reproduce the bug EACH time, I got just got 4 times without being able to reproduce it.. I'm not 100% sure but I think that I know what makes the difference : Gnucash should not automatically open the file when it starts: 1- It should be opened without any file loaded 2- THEN we should Click on "File / Open.." 3- THEN we should fill the partition 4- then we should add or remove some transaction 5- and finally we should save. It looks like the bug is not reproducible when gnucash automatically open the file when it starts, but I've nothing to confirm that this is totally caracteristic. 2- #Before all operation : total 0 #After coping the gnucash file : total 4 19331 -rw-r--r-- 1 zxz zxz 3243 2010-02-01 04:32 test #After loading it in gnucash (file / open). total 8 19331 -rw-r--r-- 1 zxz zxz 3243 2010-02-01 04:32 test 19346 -rw-r--r-- 1 zxz zxz 192 2010-02-01 04:59 test.20100201045930.log 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.7f0101.10492.LNK 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.LCK #After filling up the partition using dd. total 14572 19347 -rw-r--r-- 1 zxz zxz 14913536 2010-02-01 04:59 file 19331 -rw-r--r-- 1 zxz zxz 3243 2010-02-01 04:32 test 19346 -rw-r--r-- 1 zxz zxz 192 2010-02-01 04:59 test.20100201045930.log 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.7f0101.10492.LNK 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.LCK #After adding a transaction (without saving yet) total 14572 19347 -rw-r--r-- 1 zxz zxz 14913536 2010-02-01 04:59 file 19331 -rw-r--r-- 1 zxz zxz 3243 2010-02-01 04:32 test 19346 -rw-r--r-- 1 zxz zxz 1346 2010-02-01 05:00 test.20100201045930.log 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.7f0101.10492.LNK 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.LCK #After saving in gnucash with the Save button. 19347 -rw-r--r-- 1 zxz zxz 14913536 2010-02-01 04:59 file 19351 -rw-r--r-- 1 zxz zxz 0 2010-02-01 05:00 test 19346 -rw-r--r-- 1 zxz zxz 1346 2010-02-01 05:00 test.20100201045930.log 19331 -rw-r--r-- 1 zxz zxz 3243 2010-02-01 04:32 test.20100201050036.xac 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.7f0101.10492.LNK 19337 ---------- 2 zxz zxz 0 2010-02-01 04:59 test.LCK Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/29 ------------------------------------------------------------------------ On 2010-02-01T10:12:44+00:00 Saivann Carignan wrote: Created attachment 152715 Brand new gnucash main file, for testing Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/30 ------------------------------------------------------------------------ On 2010-02-02T00:06:27+00:00 andi5 wrote: Thanks, Saïvann, I finally could reproduce the/a bug, but I needed to turn on file compression. r18598 should improve the zlib error handling. Does it help? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/31 ------------------------------------------------------------------------ On 2010-02-02T01:44:46+00:00 Saivann Carignan wrote: ... Great! I don't know if there are others situations where this bug can happens, but in my case, even with many tries with different steps, I was not able to reproduce the bug anymore with r18598. Thanks for your work!! Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/32 ------------------------------------------------------------------------ On 2010-02-02T12:27:03+00:00 andi5 wrote: Nice. What about Windows? Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/33 ------------------------------------------------------------------------ On 2010-02-21T21:09:06+00:00 Christian Stimming wrote: The bug was never reported on windows. Hence, I think it can be closed due the comment #30. Reply at: https://bugs.launchpad.net/ubuntu/+source/gnucash/+bug/294302/comments/34 ** Changed in: gnucash Status: Unknown => Fix Released ** Changed in: gnucash Importance: Unknown => Critical -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/294302 Title: no error when partition is full, data lost To manage notifications about this bug go to: https://bugs.launchpad.net/gnucash/+bug/294302/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
