Not the first time: When an old HSQLDB crashes LO offers to restore the file. I have erroneously pressed "Yes" and the next time the queries and all will be there but the Base will show: No connection to the database. So I close the database file and the whole file will show 0 byte. No problem, a copy is there. But LibreOffice should never try to restore a database file. If I press no I could open the file with the old data without any problem. If I press "Yes" I could lose all data. That isn't restoring, that's destroying.
I tried two scenarios on Windows: 1. Created HSQL database 1.1 Created table tasks1 with wizard, saved it 1.2 Created table tasks2 with wizard, did not save it After terminating the LibreOffice process via Windows task manager and choosing "Yes" when asked for recovery next time, both tasks1 and tasks2 tables were there. Data was OK. 2. Created Firebird database 2.1 Created table tasks1 with wizard, saved it 2.2 Created table tasks2 with wizard, did not save it After terminating the task via task manager and choosing "Yes" when asked for recovery next time, tasks2 table was not there although tasks1 was present and OK. Therefore, I could NOT reproduce the issue. Maybe it is dependent on when the crash happens. But, I found that restore functionality does not work for Firebird databases, and sometimes works for the old HSQLDB databases. Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 20; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
This bug won't appear every time. It is like the bug, which wrote many backup files of a database file while editing queries or doing something else with creating databases: It will appear sometimes, and if this special bug appears it destroys the database. So it would be better not to offer the restoring of a database file. Data of the database file won't be affected, because they will only be written to the Base file when it has been closed normally. When crashing only the old data will be available in the database file. So the save way is: Don't try to restore, because you could only destroy. Do nothing instead.
Quoting from Mike on IRC: > the functionality can't depend on the DB engine. From restore PoV, it's just > picking some blobs > fyi, there's tools::isEmptyFileUrl to detect 0-byte ones Therefore, maybe different behavior in Firebird is related to something else. I also discussed the prevention of zero bytes recoveries. Also, communicating the file sizes (original and restorable), and possibly the dates, can help user choose a better option. I will file that in a separate feature request.