Emulator

I can confirm being able to reproduce this bug. It seems to have appeared around cc6db8cf26c1508ae382912bc25e64aaf12e0543,

"Merge pull request #939 from shuffle2/fix-memcard-flush2 …
shuffle2 authored 3 days ago
move the decision to delay raw memcard flushes out of the thread."

Additional note: reproduced using Paper Mario: The Thousand-Year Door.

Is it only under crashes? If so, my mistake. I was having issues while testing PRs when I noticed memcards not updating, but it could be separate.

If Dolphin crashes, I dunno.

fwiw I arbitrarily choose a delay of 15 seconds (from the last flush). This could be made quite a bit shorter (around 1 second or less, probably) without having any perf impact. So, that could be done. But generally, this is the same exact way it behaved before.

Also, memcard-folder doesn't have continuous writing at all (only when dolphin shuts down correctly), and you seem to be ok with this. The raw memcard constantly saving to disk is just a remnant of ye olden dolphin days when it would literally crash every 5 minutes in any game for no apparent reason. It's not like that anymore.

Furthermore, if you see the OSD message, then it has flushed to disk. If you see the message and you apparently lost data, that means the game has written to the memcard since the last OSD msg.

I wouldn't design any part of Dolphin (or any other software, for that matter) to never expect to crash. I'm gonna send angry letters to my local Dolphin senator until they pass a bill to reduce that flush delay and implement continuous writing for memcard folders.

For what it's worth, I do think that a shorter flush delay may be ideal. Just my $0.02.

To be honest, I was experiencing this via adding Dolphin with a flag to autoexecute Paper Mario TTYD inside of Steam Big Picture. When I would want to exit the game, I would use Big Picture's close game, which may not send a nice signal to the controlled application to close cleanly. I guess that's how I was invoking the behavior. But I will second pauldacheez, I think some gracefulness should be considered in the way of writing data that doesn't go kaput in the event of a crash.

Lastly, I'll say that with a copy of dolphin built at commit 9b10d36a85bb27681f5d48e3ced9c142a1ac6b47 (the one before the commit referenced above) the issue is not present.