BlueCobold

I have restored the header with a reference to the top_ref and table_names_ref, but it seems the data is partly scrambled. Some objects have invalid strings which crash Realm when...

In further deeper data analysis, I realised some realm-object-keys to be huge. Like '3,402,167,040,181,607,100'. How come they grew so large? Is it possible there's an issue with keys and they...

I thought so. I have replied via email to send you the decryption-key. Did you receive it?

> To which email address should the key have been sent to? I have not received anything. Sorry, I thought there was a forwarded-reply feature on github-mails. Doesn't look like....

I sent it along with a few of my own findings. Thanks for your help.

  Yes, exactly my results as well. After that block, it seems to be mostly valid data. That's why I manually restored the header as I wrote in the previous mail....

The duplicated data starts originally at 0x98EC0, a valid array. And then is "duplicated" into the header, making the file unusable.

> It is very common to have duplicated data. Whenever some part of an array is modified, a new version of the array is created by copying the whole array....

I found the following cluster-tree, related to table realm/realm-swift#10 at offset 0x1192A0: 41414141 4700000C 40870800 00000000 00000000 00000000 D80C0000 00000000 15000000 00000000 A8481700 00000000 03000000 00000000 A1520000 00000000 38650200 00000000...

This could help locating issues more easily and to restore old data in a corrupt file a lot. On the other hand, actually being ACID would help more.