Empty calibre after disk crash/replacement

[ranchero]

My e: disk crashed, fortunately, Calibre was fully backed up by File History (Windows 8.1). The computer techs installed a new drive and restored the disk from File History.

I now have ALL the books, a LOT of .db backup files (e.g. metadata (2019_05_04 03_04_43 UTC).db) and a zillion .json files

(e.g. metadata_pre_restore.db)

but an empty Calibre. The library appears to have been restored entirely but with a wiped out metadata.db file. Attempts to rebuild it resulted in empty Calibre.

I backed up the library again before experimenting, using all the suggestions I could find in the manual and forums, but I am missing something.

Can anyone point me in the right direction?

Thanks
rob

[theducks]

The prerestore is generated by the restore process. It does not exist in a working Library (and is deleted upon completion of the restore)
2 files you need
<rename the latest <dated> metadata.db to metadata.db
You should hopefully have metadata_db_prefs_backup which is the structure and settings that apply to the columns

[ranchero]

I rename dthe latest dated metadata.db to metadata.db

I did not have a metadata_db_prefs_backup, but I renamed "metadata_db_prefs_backup.json"] to "metadata_db_prefs_backup", although I was pretty sure that would fail.

Well, the rebuild failed (I used Switch/create library). This was the message.

calibre, version 3.42.0
ERROR: Failed to repair library: Restoring database failed, click Show details to see details (the metadata.db file appears untouched. There is a new metadata_db_prefs_backup.json containing only 14KB).

Traceback (most recent call last):
File "site-packages\calibre\db\restore.py", line 128, in run
File "site-packages\calibre\db\restore.py", line 281, in replace_db
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'E:\\LIBRARY\\metadata.db'

Any advice on next step? I appear to have my original library, a metadata.db file of some 14MB. Could I create a new Calibre library by exporting the data] to a new Library 2 file?

thanks rob

[theducks]

Originally Posted by ranchero

I rename dthe latest dated metadata.db to metadata.db

I did not have a metadata_db_prefs_backup, but I renamed "metadata_db_prefs_backup.json"] to "metadata_db_prefs_backup", although I was pretty sure that would fail.

Well, the rebuild failed (I used Switch/create library). This was the message.

calibre, version 3.42.0
ERROR: Failed to repair library: Restoring database failed, click Show details to see details (the metadata.db file appears untouched. There is a new metadata_db_prefs_backup.json containing only 14KB).

Traceback (most recent call last):
File "site-packages\calibre\db\restore.py", line 128, in run
File "site-packages\calibre\db\restore.py", line 281, in replace_db
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'E:\\LIBRARY\\metadata.db'

Any advice on next step? I appear to have my original library, a metadata.db file of some 14MB. Could I create a new Calibre library by exporting the data] to a new Library 2 file?

thanks rob

The filename DOES have .json as its extension
It is small because it only describes the structure (columns and type, and setting for the. No Data.
The restor processes uses the json file to create an empty table that matched the oldne.
The next step scans the folders and uses the OPF file to populate the table (this is what takes time. Read the file, validate, make the entry. Repeat)

[chaley]

Originally Posted by ranchero

Traceback (most recent call last):
File "site-packages\calibre\db\restore.py", line 128, in run
File "site-packages\calibre\db\restore.py", line 281, in replace_db
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'E:\\LIBRARY\\metadata.db'

That message says that *something* is trying to read metadata.db at the same time that calibre is using it. If E: is a network shared drive or a folder synced by Dropbox, Onedrive etc; then copy that folder to a local drive and try again.

The same thing can happen if you are using an aggressive antivirus. In this case try turning it off for the duration of the restore.