Download it now!
Bug 60880 - database file corrupted
Summary: database file corrupted
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2013-02-15 08:51 UTC by Jérôme Bouat
Modified: 2013-10-25 15:16 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

the corrupted file (1.13 MB, application/vnd.oasis.opendocument)
2013-02-15 08:51 UTC, Jérôme Bouat
an other corrupted file (1.28 MB, application/vnd.oasis.opendocument)
2013-03-14 12:48 UTC, Jérôme Bouat

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme Bouat 2013-02-15 08:51:30 UTC
Created attachment 74858 [details]
the corrupted file

I saved the attached database file and closed the LO Base.

When I tried to open it again, it proposes to choose a filter for opening it.

Options :
- quick start enabled
- save on network file system (Samba ?)

Should I select the option
"always make a backup copy" ("toujours créer une copie de sauvegarde" in French)
into the "load/saving" options ("chargement/enregistrement" in French) ?
Comment 1 Julien Nabet 2013-02-16 18:19:08 UTC
I tried to unzip the odb file (since ods, odt, odb, etc. are just zip files with a specific organization) and found that the file was corrupted, here's the output:
julien@julienPC:~/compile-libreoffice/bugs/60880_base/test$ unzip 
error []:  missing 1141780 bytes in zipfile
  (attempting to process anyway)
error []:  attempt to seek before beginning of zipfile
  (please check that you have transferred or created the zipfile in the
  appropriate BINARY mode and that you have compiled UnZip properly)
  (attempting to re-compensate)
 extracting: mimetype                
   creating: forms/
  inflating: database/data           
  inflating: database/script         
  inflating: database/backup         
  error:  invalid compressed data to inflate
file #6:  bad zipfile offset (lseek):  2318336
file #7:  bad zipfile offset (local header sig):  2325738
  (attempting to re-compensate)
file #7:  bad zipfile offset (local header sig):  2325738
   creating: reports/
  inflating: settings.xml            
   creating: META-INF/
  inflating: content.xml             
   creating: Configurations2/
  inflating: META-INF/manifest.xml   

Rainer: I rather say a Samba problem not a LO problem but perhaps I'm wrong. What do you think?
Comment 2 Jérôme Bouat 2013-03-14 12:48:17 UTC
Created attachment 76526 [details]
an other corrupted file

The bug just occurred again.

I was using also LO Calc.

I closed the database window and a dialog asked me if I wanted to save the database. I replied "yes". The window disappeared but the database file seems to be smaller than the non corrupted one.

Between the 2 corrupted files, I activated the backup copy while saving. However, this backup copy doesn't work here. Should I created an other bug for this backup copy issue ?
Comment 3 Julien Nabet 2013-03-14 13:01:35 UTC
Jérôme: Just to be sure, was a Samba share concerned during backup?
Comment 4 Jérôme Bouat 2013-03-14 13:14:53 UTC
The LO Database was on a network file system (I don't know exactly which one). I know that Samba is used for integration with Microsoft Windows XP desktop but I don't know the underlying file system.

I spoke about the "backup copy" wich appears in "options" dialog -> "load/save" -> "general" -> "save" -> "always create a backup copy". I activated this option between the 2 database corruptions.
Comment 5 Julien Nabet 2013-03-14 13:26:33 UTC
Jérôme: we need to know if the problem is because of the use of Samba (Samba bug or LO bug because it manages badly network share) or if it's a LO bug concerning backup.
Could you try this same test in local?
Comment 6 Jérôme Bouat 2013-03-14 13:29:19 UTC
Ok, I will use the database file on a local storage from now.
Comment 7 Jérôme Bouat 2013-03-14 13:51:32 UTC
Note that I never had a corrupted file on this network file systems which is daily used by me.
Comment 8 Julien Nabet 2013-03-14 14:25:33 UTC
Jérôme: if you can't reproduce this behaviour in local and always reproduce this behaviour when using Samba share (+ the fact you don't have similar problems with Samba), it can be, as I said, a LO bug dealing with network share.

Now, it could be more difficult to investigate if you can't always reproduce this bug when using network share. Could you tell if it's the case?

To put it clearly, I don't pretend I'm sure it's a Samba problem, I just would like to know which part of LO may be buggy: "backup copy" part or network share dealing.
Comment 9 QA Administrators 2013-09-24 02:01:09 UTC
Dear Bug Submitter,

This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information.

For more information about our NEEDINFO policy please read the wiki located here:

If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed.

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team
Comment 10 QA Administrators 2013-10-25 15:16:41 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided):

a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. 
Please do not:
a) respond via email 
b) update the version field in the bug or any of the other details on the top section of FDO