Func 'doFullWriteBack' in place update mmap file, will corrupt file when func is not finished but process exit.

[CodeLife2012]

  memmoveDictionary
----
  vec.reserve(dic.size());
   or (auto &itr : dic) {
        vec.push_back(&itr.second);
  }

Dict is written back follow the vec order. When crashed in the middle, recoverd key value pairs in the file are not follow the order user set it, may contain some old value and some new value, but lost the others.

So unfinished write back may put the key value pairs in a crazy state silently.

[CodeLife2012]

I test the code, aborted the process when doFullWriteBack is running. Func checkDataValid report check crc failed, then the file is cleared.

[lingol]

I don't quite understand your English. You might consider using an online-translater or just use your native language.

[lingol]

At my best guess, you were complaining about MMKV lost data if the App crash/exit while MMKV is doing a full writeback?
That's an acceptable failure. But what's your suggestion?

[CodeLife2012]

@lingol You should use a new file instead of updating the mmap file directly, clear the mmap file only when keys are actually saved to the new file.

[lingol]

And if the App crash while replacing the mmap file with the newly created file, what then?

[CodeLife2012]

@lingol Should delete old file first, then rename new file.

[LightYearsBehind]

Corrupting the file sounds like a red flag. Writing to a tmp file and renames it is a better solution, this also enable us to "rollback" should the write failed.

[lingol]

But you cannot guarantee an atomic delete & rename operation, yes?
Losing data is still possible.
And we are back to square one.

[LightYearsBehind]

How about keeping 2 files and versions it, so we don't delete any file in this case. What's left is to decide which version to use then.

[CodeLife2012]

@lingol If old file exist, recover from the old file. If crashed before rename but after delete, use the new file.

[lingol]

That whole switching file logic is way too expensive for a full writeback, which happens all the time, and finishes quite quickly if it's only a memory operation.
Given the pros and cons of each solution, I'm not sold to go for the switching file solution.

[CodeLife2012]

Func doFullWriteBack will call sync(MMKV_SYNC) to sync the m_file and m_metaFile.

[carlonzo]

it may sound a bit expensive writing the full file for each single write of an entry. for sure it will remove a class of problems related of the to corruption of a file during writing, but the cost seems quite high.

what about having this option per file? I can still see cases where data integrity is more important than performance (I'm having in mind cases where you have only a small set of key-values and a full rewrite cost is bearable) and you can leave the decision to the developer