GNOME Bugzilla – Bug 556022
Data loss on saving compressed file: GnuCash deletes file when pressing "Save" button
Last modified: 2018-06-29 22:11:13 UTC
Steps to reproduce: 1. Open a .xac file 2. Press the "Save" button (or Ctrl+S) for saving the file. 3. The .xac file will be deleted. Consequently, years of manual work may be lost. The deletion of all accounting data may go undetected for a while, because no error message pops up. Stack trace: Other information: This bug may be related to http://bugzilla.gnome.org/show_bug.cgi?id=549595 (which, however, is considered fixed). When saving, the follow strace log could be captured: strace -f -p $(pidof gnucash) 2>&1 | grep -F "accounting.gnucash.v5" [pid 10475] lstat64("/directory/obfuscated/accounting.gnucash.v5.xac.tmp-Yobz4S", 0xbfaa3088) = -1 ENOENT (No such file or directory) [pid 10475] stat64("/directory/obfuscated/accounting.gnucash.v5.xac", 0xbfaa30ac) = -1 ENOENT (No such file or directory) [pid 10705] open("/directory/obfuscated/accounting.gnucash.v5.xac.tmp-Yobz4S", O_WRONLY|O_CREAT|O_TRUNC, 0666 <unfinished ...> [pid 10475] stat64("/directory/obfuscated/accounting.gnucash.v5.xac", 0xbfaa30ac) = -1 ENOENT (No such file or directory) [pid 10475] unlink("/directory/obfuscated/accounting.gnucash.v5.xac") = -1 ENOENT (No such file or directory) [pid 10475] link("/directory/obfuscated/accounting.gnucash.v5.xac.tmp-Yobz4S", "/directory/obfuscated/accounting.gnucash.v5.xac") = 0 [pid 10475] unlink("/directory/obfuscated/accounting.gnucash.v5.xac.tmp-Yobz4S") = 0 [pid 10475] stat64("/directory/obfuscated/accounting.gnucash.v5.xac.LCK", {st_mode=S_IFREG, st_size=0, ...}) = 0 [pid 10475] unlink("/directory/obfuscated/accounting.gnucash.v5.xac") = 0 Note that if the .LCK file is manually deleted after opening the file but before hitting the save button, then the .xac file will not be deleted.
Gnucash 2.2.6 and GnuCash 2.2.7 is affected by this bug, and they are basically unusable and (worse), these versions destroy data. A note about the underlying system: * Linux kernel 2.6.27 running in x86 SMP on an ext3 filesystem.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 555173 ***
Well, this bug is still in GnuCash 2.2.9! For over a year, GnuCash now destroys its very own data. This bug is not a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=555173 , because 555173 happens "infrequently", but this bug happens always. Every time the "save" button is pressed, the .xac file is deleted.
Thanks for updating the status of this bug. However, as you might guess, this error doesn't occur at most other users' and developers' systems, so its particular cause seems to be difficult to be tracked down. First of all, does this still occur with the latest 2.3.8 (unstable) version? If at all possible, please compile that version from source and see whether it still occurs. If not, it has been fixed in the meantime and we might try to look up the change that fixed it to release an update for the 2.2.9 (stable) version. If it still occurs with 2.3.8, we would need a bunch of additional information about your system. You said the place where the file is saved is an ext3 filesystem, right? I.e. a filesystem which is probably used by many other gnucash users as well? Is there anything else you might have in use which is "un-normal"?
*** Bug 555173 has been marked as a duplicate of this bug. ***
Oh, and one additional question: Do you have the option "General" -> "Compress the data file" enabled? If yes, please disable the option and check whether the error still occurs. If disabling this option makes the error go away, the error is probably caused by thread synchronization errors in src/backend/xml/io-gncxml-v2.c where the "gzip" process is forked and the XML text is piped into the gzip process, which is supposed to write it into the file. As the reporter's system was said to be SMP, this might indeed have radically different thread timing behaviour which could explain why the error occurs here but not anywhere else.
(In reply to comment #6) > [...] > If disabling this option makes the error go away It does! > [...] However, this problem was also reproducible on a non-SMP-system. Nevertheless, maybe the .xac file needs to be of considerable size (in order to make context-switches between threads likely) to trigger the problem. Maybe you can reproduce the problem now by enabling compression and using a big (>5MB uncompressed) .xac file.
Thanks for the feedback about the compression option. Can you additionally check with the latest gnucash-2.3.8, whether the problem with enabled file compression still occurs there?
Well, using gnucash 2.3.8, I was not able to reproduce the problem with enabled file compression. Howevre, if this problem is of type race condition, I think it should be positively verified that the problem is indeed fixed, and that not just the odds of the race have changed.
Unfortunately you are right - there hasn't been any change in the gzip fork() code since 2.2.9, see http://svn.gnucash.org/trac/log/gnucash/trunk/src/backend/xml where r17949 was the 2.2.9 release. So this problem should appear with 2.3.8 just as well. Maybe you can reproduce it with some more CPU load?
Some additional questions to attempt to narrow the scope of this problem... * You write in comment #1 that your system is on ext3. Is the location where you store the data file on your local machine, or on a remote storage of some kind ? (I know there are other bugreports that suggest problems with samba, that's why I ask). * What linux distribution are you running ? * Is there some additional information in the gnucash.trace file or on the console ? The latter obviously requires you to start gnucash from a command line.
Tracing information would be helpful, indeed. For information, take a look at http://wiki.gnucash.org/wiki/Logging , the log path we are interested in is gnc.backend at level debug. I think it is weird that even the first lstat64 on the data file returns ENOENT. Do recent straces look similar?
(In reply to comment #11) > Some additional questions to attempt to narrow the scope of this problem... > > * You write in comment #1 that your system is on ext3. I can also reproduce the problem on a different (reiserfs) machine. > Is the location where > you store the data file on your local machine, or on a remote storage of some > kind ? (I know there are other bugreports that suggest problems with samba, > that's why I ask). This is just storing ona local machine. > > * What linux distribution are you running ? OpenSUSE 11.2 32-bit > > * Is there some additional information in the gnucash.trace file or on the > console ? The latter obviously requires you to start gnucash from a command > line. (In reply to comment #12) > Tracing information would be helpful, indeed. For information, take a look at > http://wiki.gnucash.org/wiki/Logging , the log path we are interested in is > gnc.backend at level debug. > > I think it is weird that even the first lstat64 on the data file returns > ENOENT. Do recent straces look similar? Unfortunately, I've been able to reproduce the problem with gnucash 2.2.9 with compression _disabled_: [pid 12239] lstat64("/directory/obfuscated/accounting.gnucash.v7.xac.tmp-wMYvax", 0xbfa2728c) = -1 ENOENT (No such file or directory) [pid 12239] stat64("/directory/obfuscated/accounting.gnucash.v7.xac", 0xbfa272b0) = -1 ENOENT (No such file or directory) [pid 12239] open("/directory/obfuscated/accounting.gnucash.v7.xac.tmp-wMYvax", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 25 [pid 12239] stat64("/directory/obfuscated/accounting.gnucash.v7.xac", 0xbfa272b0) = -1 ENOENT (No such file or directory) [pid 12239] unlink("/directory/obfuscated/accounting.gnucash.v7.xac") = -1 ENOENT (No such file or directory) [pid 12239] link("/directory/obfuscated/accounting.gnucash.v7.xac.tmp-wMYvax", "/directory/obfuscated/accounting.gnucash.v7.xac") = 0 [pid 12239] unlink("/directory/obfuscated/accounting.gnucash.v7.xac.tmp-wMYvax") = 0 [pid 12239] stat64("/directory/obfuscated/accounting.gnucash.v7.xac.LCK", {st_mode=S_IFREG, st_size=0, ...}) = 0 [pid 12239] open("/directory/obfuscated", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 25 [pid 12239] unlink("/directory/obfuscated/accounting.gnucash.v7.xac") = 0 [pid 12239] open("/directory/obfuscated/accounting.gnucash.v7.xac.20100124193237.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 24 In the second but last line, gnucash deletes the .xac file. What is weird is the third but last line (open("/directory/obfuscated", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 25). This means gnucash probably is scanning the directory and wants to delete something later. Maybe it wants to delete the LCK file but instead hits the .xac file?
What is more interesting is that the third line also fails with code 25. This is the open command that should create the new file to save to. I'm afraid I don't know the xml backend code well enough to know what happens exactly and where it goes wrong. So I'm still trying to narrow down the cause. You say you can reproduce this problem with compression disabled as well. To be clear, does that mean you 1. have the option to compress disabled in the preferences 2. open an uncompressed file 3. hit save Or is only the option disabled, but the file you open is still compressed ? A more complete trace file would help a lot, as Andreas asked in comment #12. You have obfuscated the path. I respect that choice but it removes potential clues to the problem. Is the path somewhere in your home directory ? Does the path contain unusual characters like spaces, accents, punctuation ? Have you tried to save the datafile in another directory ?
If open(2) returns 25, then that is the file descriptor and the open call succeeded! As I said, the stat on the data file (second line from top) should not fail with ENOENT (Error NO ENTry). After saving a file, GnuCash will remove some LCK files (older and not the active one) and files with a name of the form /directory/obfuscated/accounting.gnucash.v7.%Y%m%d%H%M%S.{xac,log} old enough, so your data file should not match... See http://svn.gnucash.org/trac/browser/gnucash/trunk/src/backend/xml/gnc-backend-xml.c#L737 . You might want to go to the preferences and disable log/xac file removal by setting the value to 0. Tracing would help. Or complete steps (directory names, file name, nothing obfuscated, from scratch). Plus all that Geert already said :)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
This looks like it is the same as bug #593479, which I just wrote a patch for. Marking as duplicate of that bug, since that one is at least still open. *** This bug has been marked as a duplicate of bug 593479 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=556022. Please update any external references or bookmarks.