However abusive there hasn't been one time a battery pull didn't fix it.
Heh, I could count at least
two times just from your side
Add at least one SD card damaged by sd_uhs and one CF card
damaged by my own code (which I thought to be harmless before running it).
And a bunch of other similar events that happened to other developers (dfort's EOS M, chris_overseas' 5D3 and Greg's 500D are just the ones I remember right now). In all these cases, the issue was from faulty ML code (invalid value for some property). These were recovered.
Yes, the probability of things going wrong is low, but quite a bit above zero. That applies to all ML builds.
Speaking corrupted files I had some of that related to sd_uhs before adding back reconfiguration fix yesterday.
With all the recent testing, I still consider sd_uhs extremely unreliable (based on my own experience with it). There are two major issues: one is
thread safety during card reconfiguration, and the other is signal timing likely on the edge (I've got benchmarks running in LiveView, but failing outside, or viceversa, on some cards).
The safety level i consider to be very high...
I disagree - there are so many things that could go wrong.
This article gives some pretty good background info, although it's not specific to our project.
This one was written back in 2012, when I didn't really know what I was doing.
The worst issue comes from the way DryOS is designed - any task can write anywhere into RAM (even on memory belonging to other tasks). Then, at shutdown, Canon code writes stuff into their persistent memories - one of them being the main ROM (that's right, they reflash the ROM at every shutdown). It's not hard to imagine a sequence of events that would result in garbage written into ROM, resulting a camera that doesn't boot. Wait, it actually happened - two years ago I've bricked quite a few 5D3's with early crop_rec_4k builds (luckily recovered all of them, to my knowledge).
So, one of my unfinished quests is to find a way to
prevent Canon code form reflashing the ROM. Ideally, by disabling ROM writes at hardware level, to keep the camera safe even from reflashing code called by mistake. Current status: if you end up calling e.g.
EraseSectorOfRom (even indirectly or unintentionally) with the wrong arguments, you might end up erasing the bootloader, and I won't be able to recover the camera. That didn't happen yet, to my knowledge, but it is theoretically possible.
Another thing I've started to think about lately, is how to prevent data loss in the case of hard crash, power cutoff or other stuff like that. For example, ML could create some backups of the FAT tables. I might even be able to completely undo a card format, after the fact. Or, if you record a long MLV file and there is a crash / power cutoff / whatever the middle of recording, ML should be able to recover that file at the next reboot (currently it doesn't). Or, even while transferring the files to PC, a flaky USB connection could result in data loss (it happened to me some years ago, and a backup of the FAT would have saved the day).
Sorry for the off-topic.
