Convert wt file to JSON standard plain text??

[Michael Freitter]

Hello,

I have the data folder from my mongodb, that do not work.

So I was happy, if I can read the information in the collections.

If I open the *.wt files, so same word I can read, but the many characters I can't read.

How can I convert the *.wt file in standard, readable  JSON plain text files?

Thank you!

   Michael

[Michael Freitter]

Hello,

nobody have an idea, how can I convert the data from a wt file in a plain text.

I have read, that mongodb store the information in JSON structure.

How can I find this JSON structure in the files?

Thank you!

   Michael

[Kevin Adistambha]

Hi Michael,

I have the data folder from my mongodb, that do not work.

Could you clarify what “do not work” means? Does MongoDB refuses to start? If so, could you post the error message?

How can I convert the *.wt file in standard, readable JSON plain text files?

The .wt files cannot be “converted” to readable text files, since they’re stored in very specific format, with compression, with encryption (if applicable), etc.
If you’re having issues with MongoDB not starting, please post:

• The error messages
• The MongoDB version you’re using

Best regards,
Kevin

​

[Michael]

Hi Kevin,

thank you very much for your support!

> Could you clarify what “do not work” means?

If I want to access to my application (wekan) I can't access:

Thias message is displayed: Firefox can't connect to the server 192.168.178.151

I have a wekan application installed with docker.

If I send the command "docker ps" I see this:

CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                              PORTS               NAMES
78c18f059ddb        quay.io/wekan/wekan   "node /build/main.js"    2 weeks ago         Restarting (1) About a minute ago                       wekan-app
e48b55e5c01e        mongo:3.2.21          "docker-entrypoint.s…"   2 weeks ago         Restarting (14) 37 seconds ago                          wekan-db
0db6f63c0463        mongo:3.2.21          "docker-entrypoint.s…"   2 weeks ago         Restarting (14) 50 seconds ago                          wekan-mongodb_wekandb_run_1_9a57c647c8dc

The collection files are stored in the folder /var/lib/docker/volumes/wekan-mongodb_wekan-db/_data

Where stored mongodb the error log files?

Thank you!

   Michael

[Kevin Adistambha]

Hi Michael

If I want to access to my application (wekan) I can’t access:
Thias message is displayed: Firefox can’t connect to the server 192.168.178.151

This sounds like a Docker issue. I’m not sure how you installed Wekan and why it worked before (I assumed so since you mentioned that you have data in it), but typically this was caused by network misconfiguration in Docker, or was caused by firewall. There could also be other issues in your Docker deployment that we are ignorant about.

The collection files are stored in the folder /var/lib/docker/volumes/wekan-mongodb_wekan-db/_data

You might be able to install MongoDB (I assume you are on Linux). However, once it was installed, instead of starting MongoDB as a service, you may be able to execute something like:

$ mongod --dbpath /var/lib/docker/volumes/wekan-mongodb_wekan-db/_data <other relevant mongod parameters you require>

to run a MongoDB server using that directory as the dbpath. You can then examine the content of the database using the mongo shell, or export them using mongoexport.

Best regards,
Kevin

​

[Michael]

Hello,

I have installed mongo, but if I call "mongo" this error occured:

root@wekan:/var/lib/docker/volumes/wekan-mongodb_wekan-db/_data/journal# mongo
MongoDB shell version v3.4.19
connecting to: mongodb://127.0.0.1:27017
2019-02-27T18:58:32.809+0000 W NETWORK  [thread1] Failed to connect to 127.0.0.1:27017, in(checking socket for error after poll), reason: Connection refused
2019-02-27T18:58:32.809+0000 E QUERY    [thread1] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed :
connect@src/mongo/shell/mongo.js:240:13
@(connect):1:6
exception: connect failed

What can I do?

[Kevin Adistambha]

Hi,

reason: Connection refused

That means the server is not running.

Did you run mongod --dbpath <the wekan database directory>?

Kevin

​

[Michael]

Yes, this text is writting:

2019-02-27T22:49:32.943+0000 I CONTROL  [initandlisten] MongoDB starting : pid=25446 port=27017 dbpath=/var/lib/docker/volumes/wekan-mongodb_wekan-db/_data 64-bit host=wekan
2019-02-27T22:49:32.944+0000 I CONTROL  [initandlisten] db version v3.4.19
2019-02-27T22:49:32.944+0000 I CONTROL  [initandlisten] git version: a2d97db8fe449d15eb8e275bbf318491781472bf
2019-02-27T22:49:32.944+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.2n  7 Dec 2017
2019-02-27T22:49:32.944+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2019-02-27T22:49:32.944+0000 I CONTROL  [initandlisten] modules: none
2019-02-27T22:49:32.945+0000 I CONTROL  [initandlisten] build environment:
2019-02-27T22:49:32.945+0000 I CONTROL  [initandlisten]     distmod: ubuntu1604
2019-02-27T22:49:32.945+0000 I CONTROL  [initandlisten]     distarch: x86_64
2019-02-27T22:49:32.945+0000 I CONTROL  [initandlisten]     target_arch: x86_64
2019-02-27T22:49:32.945+0000 I CONTROL  [initandlisten] options: { storage: { dbPath: "/var/lib/docker/volumes/wekan-mongodb_wekan-db/_data" } }
2019-02-27T22:49:32.946+0000 W -        [initandlisten] Detected unclean shutdown - /var/lib/docker/volumes/wekan-mongodb_wekan-db/_data/mongod.lock is not empty.
2019-02-27T22:49:32.975+0000 I -        [initandlisten] Detected data files in /var/lib/docker/volumes/wekan-mongodb_wekan-db/_data created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-02-27T22:49:32.975+0000 W STORAGE  [initandlisten] Recovering data from the last clean checkpoint.
2019-02-27T22:49:32.976+0000 I STORAGE  [initandlisten]
2019-02-27T22:49:32.976+0000 I STORAGE  [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-02-27T22:49:32.976+0000 I STORAGE  [initandlisten] **          See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-02-27T22:49:32.976+0000 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=484M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),verbose=(recovery_progress),
2019-02-27T22:49:36.471+0000 E STORAGE  [initandlisten] WiredTiger error (0) [1551307776:471820][25446:0x7fab0ec64180], file:WiredTiger.wt, WT_CURSOR.next: read checksum error for 32768B block at offset 4096: block header checksum of 4109981386 doesn't match expected checksum of 1944837216
2019-02-27T22:49:36.472+0000 E STORAGE  [initandlisten] WiredTiger error (0) [1551307776:472102][25446:0x7fab0ec64180], file:WiredTiger.wt, WT_CURSOR.next: WiredTiger.wt: encountered an illegal file format or internal value
2019-02-27T22:49:36.472+0000 E STORAGE  [initandlisten] WiredTiger error (-31804) [1551307776:472863][25446:0x7fab0ec64180], file:WiredTiger.wt, WT_CURSOR.next: the process must exit and restart: WT_PANIC: WiredTiger library panic
2019-02-27T22:49:36.473+0000 I -        [initandlisten] Fatal Assertion 28558 at src/mongo/db/storage/wiredtiger/wiredtiger_util.cpp 365
2019-02-27T22:49:36.473+0000 I -        [initandlisten]

***aborting after fassert() failure


2019-02-27T22:49:36.507+0000 F -        [initandlisten] Got signal: 6 (Aborted).

 0x55df645867d1 0x55df645859e9 0x55df64585ecd 0x7fab0d7ce890 0x7fab0d409e97 0x7fab0d40b801 0x55df6381a9c5 0x55df6428a7f6 0x55df63825042 0x55df63825267 0x55df638254c9 0x55df64e964b5 0x55df64eb001b 0x55df64eb6eed 0x55df64ecfbe1 0x55df64e9b969 0x55df64ef49c3 0x55df64f866a1 0x55df64f86b87 0x55df64eeb7e7 0x55df64ee3c5b 0x55df6426ec1f 0x55df64267312 0x55df641595e0 0x55df63806dc3 0x55df63826876 0x7fab0d3ecb97 0x55df63886a29
----- BEGIN BACKTRACE -----
{"backtrace":[{"b":"55DF62FDA000","o":"15AC7D1","s":"_ZN5mongo15printStackTraceERSo"},{"b":"55DF62FDA000","o":"15AB9E9"},{"b":"55DF62FDA000","o":"15ABECD"},{"b":"7FAB0D7BC000","o":"12890"},{"b":"7FAB0D3CB000","o":"3EE97","s":"gsignal"},{"b":"7FAB0D3CB000","o":"40801","s":"abort"},{"b":"55DF62FDA000","o":"8409C5","s":"_ZN5mongo32fassertFailedNoTraceWithLocationEiPKcj"},{"b":"55DF62FDA000","o":"12B07F6"},{"b":"55DF62FDA000","o":"84B042","s":"__wt_eventv"},{"b":"55DF62FDA000","o":"84B267","s":"__wt_err"},{"b":"55DF62FDA000","o":"84B4C9","s":"__wt_panic"},{"b":"55DF62FDA000","o":"1EBC4B5","s":"__wt_bm_read"},{"b":"55DF62FDA000","o":"1ED601B","s":"__wt_bt_read"},{"b":"55DF62FDA000","o":"1EDCEED","s":"__wt_page_in_func"},{"b":"55DF62FDA000","o":"1EF5BE1"},{"b":"55DF62FDA000","o":"1EC1969","s":"__wt_btcur_next"},{"b":"55DF62FDA000","o":"1F1A9C3"},{"b":"55DF62FDA000","o":"1FAC6A1"},{"b":"55DF62FDA000","o":"1FACB87","s":"__wt_txn_recover"},{"b":"55DF62FDA000","o":"1F117E7","s":"__wt_connection_workers"},{"b":"55DF62FDA000","o":"1F09C5B","s":"wiredtiger_open"},{"b":"55DF62FDA000","o":"1294C1F","s":"_ZN5mongo18WiredTigerKVEngineC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_PNS_11ClockSourceES8_mbbbb"},{"b":"55DF62FDA000","o":"128D312"},{"b":"55DF62FDA000","o":"117F5E0","s":"_ZN5mongo20ServiceContextMongoD29initializeGlobalStorageEngineEv"},{"b":"55DF62FDA000","o":"82CDC3"},{"b":"55DF62FDA000","o":"84C876","s":"main"},{"b":"7FAB0D3CB000","o":"21B97","s":"__libc_start_main"},{"b":"55DF62FDA000","o":"8ACA29","s":"_start"}],"processInfo":{ "mongodbVersion" : "3.4.19", "gitVersion" : "a2d97db8fe449d15eb8e275bbf318491781472bf", "compiledModules" : [], "uname" : { "sysname" : "Linux", "release" : "4.15.0-43-generic", "version" : "#46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018", "machine" : "x86_64" }, "somap" : [ { "b" : "55DF62FDA000", "elfType" : 3, "buildId" : "12B87D853091E4006EC9C6B297F80E12260F42AF" }, { "b" : "7FFD01DF2000", "path" : "linux-vdso.so.1", "elfType" : 3, "buildId" : "FAD1928AF4EC8CD98E4113D1E2C6A038DDFE99DC" }, { "b" : "7FAB0E7E0000", "path" : "/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0", "elfType" : 3, "buildId" : "0D054641049B9747C05D030262295DFDFDD3055D" }, { "b" : "7FAB0E39D000", "path" : "/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", "elfType" : 3, "buildId" : "9C228817BA6E0730F4FCCFAC6E033BD1E0C5620A" }, { "b" : "7FAB0E195000", "path" : "/lib/x86_64-linux-gnu/librt.so.1", "elfType" : 3, "buildId" : "9826FBDF57ED7D6965131074CB3C08B1009C1CD8" }, { "b" : "7FAB0DF91000", "path" : "/lib/x86_64-linux-gnu/libdl.so.2", "elfType" : 3, "buildId" : "25AD56E902E23B490A9CCDB08A9744D89CB95BCC" }, { "b" : "7FAB0DBF3000", "path" : "/lib/x86_64-linux-gnu/libm.so.6", "elfType" : 3, "buildId" : "A33761AB8FB485311B3C85BF4253099D7CABE653" }, { "b" : "7FAB0D9DB000", "path" : "/lib/x86_64-linux-gnu/libgcc_s.so.1", "elfType" : 3, "buildId" : "92E0BE1929D28508CF9C6D5754C7EB48C12255B3" }, { "b" : "7FAB0D7BC000", "path" : "/lib/x86_64-linux-gnu/libpthread.so.0", "elfType" : 3, "buildId" : "28C6AADE70B2D40D1F0F3D0A1A0CAD1AB816448F" }, { "b" : "7FAB0D3CB000", "path" : "/lib/x86_64-linux-gnu/libc.so.6", "elfType" : 3, "buildId" : "B417C0BA7CC5CF06D1D1BED6652CEDB9253C60D0" }, { "b" : "7FAB0EA48000", "path" : "/lib64/ld-linux-x86-64.so.2", "elfType" : 3, "buildId" : "64DF1B961228382FE18684249ED800AB1DCEAAD4" } ] }}
 mongod(_ZN5mongo15printStackTraceERSo+0x41) [0x55df645867d1]
 mongod(+0x15AB9E9) [0x55df645859e9]
 mongod(+0x15ABECD) [0x55df64585ecd]
 libpthread.so.0(+0x12890) [0x7fab0d7ce890]
 libc.so.6(gsignal+0xC7) [0x7fab0d409e97]
 libc.so.6(abort+0x141) [0x7fab0d40b801]
 mongod(_ZN5mongo32fassertFailedNoTraceWithLocationEiPKcj+0x0) [0x55df6381a9c5]
 mongod(+0x12B07F6) [0x55df6428a7f6]
 mongod(__wt_eventv+0x3D7) [0x55df63825042]
 mongod(__wt_err+0x9D) [0x55df63825267]
 mongod(__wt_panic+0x2E) [0x55df638254c9]
 mongod(__wt_bm_read+0x135) [0x55df64e964b5]
 mongod(__wt_bt_read+0x1FB) [0x55df64eb001b]
 mongod(__wt_page_in_func+0x11DD) [0x55df64eb6eed]
 mongod(+0x1EF5BE1) [0x55df64ecfbe1]
 mongod(__wt_btcur_next+0x399) [0x55df64e9b969]
 mongod(+0x1F1A9C3) [0x55df64ef49c3]
 mongod(+0x1FAC6A1) [0x55df64f866a1]
 mongod(__wt_txn_recover+0x487) [0x55df64f86b87]
 mongod(__wt_connection_workers+0x37) [0x55df64eeb7e7]
 mongod(wiredtiger_open+0x197B) [0x55df64ee3c5b]
 mongod(_ZN5mongo18WiredTigerKVEngineC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_PNS_11ClockSourceES8_mbbbb+0x70F) [0x55df6426ec1f]
 mongod(+0x128D312) [0x55df64267312]
 mongod(_ZN5mongo20ServiceContextMongoD29initializeGlobalStorageEngineEv+0x6B0) [0x55df641595e0]
 mongod(+0x82CDC3) [0x55df63806dc3]
 mongod(main+0x966) [0x55df63826876]
 libc.so.6(__libc_start_main+0xE7) [0x7fab0d3ecb97]
 mongod(_start+0x29) [0x55df63886a29]
-----  END BACKTRACE  -----
Aborted

[Kevin Adistambha]

Hi,

file:WiredTiger.wt, WT_CURSOR.next: read checksum error for 32768B block at offset 4096: block header checksum of 4109981386 doesn’t match expected checksum of 1944837216

This means that there is data corruption on your MongoDB data. The cause could be many things, including hardware failure, power failure on a cached SSD without backing battery, memory corruption, among many.

MongoDB 4.0 has an improved repair facilities, however this avenue is made a bit complex because you’re using MongoDB 3.4, which is 2 major versions behind.

What I can recommend to proceed:

1. Have a look at the repair procedure and all warnings in the Recover a Standalone after an Unexpected Shutdown page.
2. Create a backup of the database path
3. Copy the backed-up database path into another machine
4. Install MongoDB 4.0 in the other machine, so you can preserve the working MongoDB 3.4 installation in the current machine
5. Attempt the repair procedure in the other machine using MongoDB 4.0 binaries
6. Once the repair process was done (assuming it’s successful), copy the repaired data files back to the original machine. Note that it’s safer to have this copy on a separate directory and don’t overwrite the original Wekan data directory
7. Try to run mongod --dbpath <new repaired data files> using the existing MongoDB 3.4 deployment in your original machine
8. Try to connect to the server using the mongo shell, or dump the database contents using mongodump, mongoexport, or similar

Essentially, try to do the repair on another machine, using a backup copy of the original data.

Please note that since data corruption is the main issue, there could be no guarantee that this method will work.

Best regards,
Kevin

​

[Michael]

Hello,

now I have create a new VM (mongo-repair) with mongo 4.0 and copy the corrupted file to the VM to /home/michael/mongo_data

Then I start "sudo mongod --dbpath /home/michael/mongo_data --repair"

After I start mongo with "sudo mongod --dbpath /home/michael/mongo_data" and also this mesage occure:

2019-03-03T14:16:45.577+0000 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-03T14:16:45.583+0000 I CONTROL  [initandlisten] MongoDB starting : pid=15405 port=27017 dbpath=/home/michael/mongo_data 64-bit host=mongo-rep
2019-03-03T14:16:45.583+0000 I CONTROL  [initandlisten] db version v4.0.6
2019-03-03T14:16:45.584+0000 I CONTROL  [initandlisten] git version: caa42a1f75a56c7643d0b68d3880444375ec42e3
2019-03-03T14:16:45.584+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.0g  2 Nov 2017
2019-03-03T14:16:45.584+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2019-03-03T14:16:45.584+0000 I CONTROL  [initandlisten] modules: none
2019-03-03T14:16:45.584+0000 I CONTROL  [initandlisten] build environment:
2019-03-03T14:16:45.585+0000 I CONTROL  [initandlisten]     distmod: ubuntu1804
2019-03-03T14:16:45.585+0000 I CONTROL  [initandlisten]     distarch: x86_64
2019-03-03T14:16:45.585+0000 I CONTROL  [initandlisten]     target_arch: x86_64
2019-03-03T14:16:45.585+0000 I CONTROL  [initandlisten] options: { storage: { dbPath: "/home/michael/mongo_data" } }
2019-03-03T14:16:45.585+0000 E STORAGE  [initandlisten] Failed to set up listener: SocketException: Address already in use
2019-03-03T14:16:45.585+0000 I CONTROL  [initandlisten] now exiting
2019-03-03T14:16:45.586+0000 I CONTROL  [initandlisten] shutting down with code:48

I think, the repair did not work? Correct?

Thank you!

       Michael

​

[Robert Cochran]

Hi,

This page lists the MongoDB exit codes. A careful reading of the explanation for exit code 48 plus the error message suggests that port 27017 on the virtual machine is being used by another process. You probably should either remove that process, or start MongoDB on a different port with the --port option. For example --port 27018. 

Thanks so much

Bob

[Michael]

Hi,

thank's! I have now call the staement "sudo mongod --dbpath /home/michael/mongo_data --port 27018"

2019-03-03T20:53:59.175+0000 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-03T20:53:59.188+0000 I CONTROL  [initandlisten] MongoDB starting : pid=1245 port=27018 dbpath=/home/michael/mongo_data 64-bit host=mongo-repair
2019-03-03T20:53:59.188+0000 I CONTROL  [initandlisten] db version v4.0.6
2019-03-03T20:53:59.188+0000 I CONTROL  [initandlisten] git version: caa42a1f75a56c7643d0b68d3880444375ec42e3
2019-03-03T20:53:59.188+0000 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.1.0g  2 Nov 2017
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten] allocator: tcmalloc
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten] modules: none
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten] build environment:
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten]     distmod: ubuntu1804
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten]     distarch: x86_64
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten]     target_arch: x86_64
2019-03-03T20:53:59.189+0000 I CONTROL  [initandlisten] options: { net: { port: 27018 }, storage: { dbPath: "/home/michael/mongo_data" } }
2019-03-03T20:53:59.190+0000 F STORAGE  [initandlisten] An incomplete repair has been detected! This is likely because a repair operation unexpectedly failed before completing. MongoDB will not start up again without --repair.
2019-03-03T20:53:59.190+0000 F -        [initandlisten] Fatal Assertion 50922 at src/mongo/db/storage/storage_engine_init.cpp 86
2019-03-03T20:53:59.190+0000 F -        [initandlisten]

***aborting after fassert() failure

So I have see " An incomplete repair has been detected! This is likely because a repair operation unexpectedly failed before completing. MongoDB will not start up again without --repair" and so I have again start "sudo mongod --dbpath /home/michael/mongo_data --repair"

2019-03-03T20:57:10.355+0000 F CONTROL  [initandlisten] ** IMPORTANT: UPGRADE PROBLEM: The data files need to be fully upgraded to version 3.6 before attempting an upgrade to 4.0; see http://dochub.mongodb.org/core/4.0-upgrade-fcv for more details.
2019-03-03T20:57:10.355+0000 I STORAGE  [initandlisten] WiredTigerKVEngine shutting down
2019-03-03T20:57:10.356+0000 I STORAGE  [initandlisten] Shutting down session sweeper thread
2019-03-03T20:57:10.356+0000 I STORAGE  [initandlisten] Finished shutting down session sweeper thread
2019-03-03T20:57:10.454+0000 I STORAGE  [initandlisten] shutdown: removing fs lock...
2019-03-03T20:57:10.455+0000 I CONTROL  [initandlisten] now exiting
2019-03-03T20:57:10.455+0000 I CONTROL  [initandlisten] shutting down with code:62

I have looked for the code 62: Returned by mongod if the datafiles in --dbpath are incompatible with the version of mongod currently running.

How can I upgrade a currupt 3.6 version to 4.0? Or must I remove mongo 4.0 and install 3.6 and --repair again?

Thank you!

Then I read

[Kevin Adistambha]

Hi Michael

I have looked for the code 62: Returned by mongod if the datafiles in —dbpath are incompatible with the version of mongod currently running.

How can I upgrade a currupt 3.6 version to 4.0? Or must I remove mongo 4.0 and install 3.6 and —repair again?

This error message is a bit misleading in your case.

It is basically saying that the mongod process (the 4.0 binaries) cannot start because you have an outdated data files.

If the repair process was completed without any error using the 4.0 binaries, it’s time to try steps 6 and beyond in my previous post. To recap my previous email:

1. Once the repair process was done (assuming it’s successful), copy the repaired data files back to the original machine. Note that it’s safer to have this copy on a separate directory and don’t overwrite the original Wekan data directory
2. Try to run mongod --dbpath <new repaired data files> using the existing MongoDB 3.4 deployment in your original machine
3. Try to connect to the server using the mongo shell, or dump the database contents using mongodump, mongoexport, or similar

Please note that even if it can be started, it might be missing data that is unrecoverable. This method simply try to salvage what could be salvaged.

Best regards,
Kevin

​