Created attachment 105448 [details] File opens as writer document despite it should be a database (see bug report) ORIGINAL BUG TITLE: FILESAVE: Corrputed database file when saving ISSUE(S): Sometimes, while I was working on a report and saved that, the save button in the main application remained greyed out so I was unable to save the changes to the database. I was not prompted whether I wanted to save the changes when I closed Libre Office and my changes were thus silently discarded. Sometimes, the main application window refused to close and just did nothing when I attempted to close it though the menu "Datei -> Libre Office beenden" or when clicking the "red x" provided by the OS. But all of that was tolerable until, at some point, the database file got corrupted after saving. It was then opened as text document in writer, displaying four hash characters (####). I was able to recover an old version of it from the %temp% folder and merge my work to the report from the newer but corrupt odb file using 7z. SUGGESTION: I suggest you to add a warning that things like this may happen. EXPECTATION: A version 4.3.0.4 (win x64) should not corrupt files; in no circumstances. REPRODUCING: I have no time currently. But moving some elements around, starting the formula editor and generating the report was usually enough to get one of the file save problems very quickly. UNRELATED NOTE: As an unrelated note, after this experience, I think I am going to switch back to sqlite (or even just JSON) + self written Qt C++ and JS code. This has provided me with very good stability recently; I was just hoping that there would be something for people not so familiar with programming.
Created attachment 105449 [details] File recovered by merging the report from the corrupt file into an old copy from %temp%
Unfortunately without more there's really nothing we can do. Closing as INVALID. If you can get reproducible steps together please feel free to add them and then set the bug back to UNCONFIRMED. Please understand that our goal is to reproduce problems so that we can diagnose what went wrong - just saying "this happened" doesn't give us anything to reproduce by.
(In reply to comment #2) > Please understand that our goal is to reproduce problems so that we can > diagnose what went wrong - just saying "this happened" doesn't give us > anything to reproduce by. For this reason, I attached the corrupted odb file. I guess someone with sufficient knowledge of this file format can very easily find out the reason it opens now with writer instead of base. So what does it mean if it starts with writer? That the zip file was not fully written or that some file inside the archive is corrupt. Note that the more information you I have, I will me more likely to get an idea how to reproduce it. Apart from that, I still suggest to add a warning to the UI on first use that base is not stable/ and or always create backups of the whole odb file *by default*. This seems to be justified as a query for corrupt base files https://bugs.freedesktop.org/buglist.cgi?order=Importance&list_id=462365&short_desc=corrupt&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=PLEASETEST&short_desc_type=allwordssubstr&component=Database&component=Libreoffice&product=LibreOffice returned 36 bugs, the majority of them created less than 12 months ago. Given that base is certainly less extensively used than writer or calc, I bet this is enough evidence. Please note that some bugs are inherently hard to reproduce (see bug 75717 for example), if they for example need a complex chain of actions in advance to enter in corrupt state, or time-dependent bugs, e.g. only happening on high CPU load by other programs, etc. Joel, considering the bug's description, can you recommend me a tool assisting me detecting whether libre office enters into a broken state (e.g. buffer overflows, other debugging tools and information)? BTW, reading Bug 60880#c10 it seems to me that this message could be improved linking to those tools able to assist debugging LO for newcomers. Do you recommend me filing bugs like that in future, even if I am unable to reproduce? I just wonder whether it's worth the efforts, OTH I think it's important to somehow track the occurrences of issues like that? Seeing other bug reports about corrupted files, I'd like to mention that my file system otherwise works well. The file was located on a local ntfs system; the drive is a relatively new SSD.
We're not going to add a warning - the software comes with a license that says basically comes as is. We're not even sure how this happened so adding some generic warning that "stuff might happen" is not useful for anyone. That being said - you're right, maybe the db is sufficient for a developer to see what happened. Moving back to UNCONFIRMED for now
Have had a look at the database-file. When I extract the whole file there isn't extracted the mimetype-information of the *.odb-file. So I took an empty new database, put all the content of database, reports, content.xml and settings.xml instead of the content of the new database-file into the packed file and could open the *.odb-file with a table "Microspecies" (141 rows) and a report, which couldn't be opened.
@Lionel - any thoughts on this one?
Thoughts on embedded hsqldb and known legendary instability ? IMHO this has been known for years, the forums and mailing lists are rife with people complaining about mangled data, that should be warning enough - the problem pre-existed the creation of the LO project, ever since Sun took the decision to integrate the hsqldb engine as default, back when OOo 2 was released, so at least 10 years. Of course, it is inherently problematic that embedded hsqldb remains the default, but until we have a suitable replacement, there's probably not much we can do about that with current resources.
(In reply to Alex Thurgood from comment #7) > Thoughts on embedded hsqldb and known legendary instability ? It isn't the instability of HSQLDB. Most of the problems appear while the data were saved in the same packed file as all other things. It wouldn't be better with an internal Firebird. Most instable element of Base is the Report-Builder, and there the crating of a report. When I create a report I press very often the Button to save all this to to the Base-File and the from the Base-GUI to the harddisk. There should be a permanent backup from the *.odb-file to the backup-folder of LibreOffice. It would help to save data. You could find this as a macro in the Base-Handbook.
the "unzip" tool complains about various errors in the attachment - very odd, i've never seen that before (but then i rarely look at Base bugs).
It won't solve the problem but upgrading to last stable LO version, ie 4.3.4, may help a bit. Indeed, 4.3.0.4 is the first non Beta version of 4.3 branch. Again, it's not the solution, just a start. About hsqldb, hope an upgrade from 1.8 to 2.3 release (I don't know when) may help to improve LO stability waiting by the full adoption of Firebird which may take some time.
Adding self to CC if not already on
(In reply to Rainer Rillke from comment #0) > File opens as writer document despite it should be a database (see bug > report) > ... > FILESAVE: Corrputed database file when saving Can we reproduce the problem of getting a corrupted database file when saving? What's next here?
I'm sorry your data file got corrupted. Since we don't know how to reproduce it, realistically I don't think much will happen. The corrupted file is not even recognised by "file" as a ZIP file anymore. I treated the corrupted file with "zip -F", and then it opened correctly, table and report. I'm not sure what to do QA-wise to this bug... I recognise it happened, but keeping it open without clear reproduction steps is not going to achieve anything. Robinson, what's your opinion? (In reply to robert from comment #8) > There should be a permanent backup from the *.odb-file to the backup-folder > of LibreOffice. There is an autosave every XX minutes; that's what the autorecovery uses; AFAIK one can "just" copy the autosave file before restarting LibreOffice; I think it is somewhere in ~/.config/libreoffice/4/. See "tools / options / load/save / general / save autorecovery information every XX minutes". (In reply to robert from comment #8) > (In reply to Alex Thurgood from comment #7) >> Thoughts on embedded hsqldb and known legendary instability ? > It isn't the instability of HSQLDB. Most of the problems appear while the > data were saved in the same packed file as all other things. It wouldn't be > better with an internal Firebird. I'm not so sure. Embedded HSQLDB does rather horrible tricks to "fake" that the database is saved to the odb after each transaction; I wouldn't be too surprised if the file corruption problems came from there. Embedded Firebird by design does not (and requires a "save" to save the data in the odb file).
(In reply to Lionel Elie Mamane from comment #13) > I'm not sure what to do QA-wise to this bug... I recognise it happened, but > keeping it open without clear reproduction steps is not going to achieve > anything. Robinson, what's your opinion? We really need to be able to reproduce the problem to try to track down what caused it. We could stick this bug in NEEDINFO for a while, but I'm going to just go ahead and RESOLVE it as WORKSFORME, as we can't reproduce the problem by following the steps. Rainer: If you experience this bug again, please leave another comment. It's really helpful that you've filed this report, as this provides more information in the event that someone else runs into the same bug.
That's why you should have used https://spinbackup.com/products/google-apps-backup/ from Spinbackup. They would not have allowed your data to get corrupted. I hope that you will take some time to check it out.
That's why you should have used https://spinbackup.com/products/google-apps-backup/ from Spinbackup. They would not have allowed your data to get corrupted. My opinion is that its the best product in the business. I hope that you will take some time to check it out.