At this point you must know that if you buy a mac you are surrendering any claim on your third party apps surviving between updates. Irritating, yes, but not surprising.
The only way this ever worked was pure luck, relying on the OS:
- Writing file blocks in the desired order — which is not guaranteed.
- Writing filesystem metadata in the desired order — also not guaranteed.
- Not caching any important pages, so that the VM page cache isn't out-of-sync with the block device after it silently discards writes.
- Not caching any important filesystem metadata, so that the filesystem implementation isn't out-of-sync.
I'm surprised (1) anyone thought this was anything other than a risky hack, and (2) not only did RPi actually ship this broken design, but did so in ROM, and thus cannot patch it.
[edit]
Surprised at the downvotes for posting a technical rebuttal to an inflammatory comment.
As someone with a few decades in OS/kernel development, this doesn't seem like a controversial or even difficult question. The implementation is broken and cannot work reliably.
If you disagree, then please explain why you believe the USB mass storage emulation is not broken.
https://github.com/microsoft/uf2
- Data is divided into 512 byte blocks, which lines up with the mass storage transfer size.
- Each block has an identifying magic sequence, a payload address, and size, which can be used to identify the destination.
- This allows the emulated storage to ignore metadata blocks and to handle out-of-order and repeated blocks.UF2 is just the file format, though. The mechanism for reading/writing UF2 files is via the emulated USB mass storage, which is fundamentally broken.
The USB storage device responds to SCSI write commands with a success status, but actually throws away data, such that a successive read does not return the previously written blocks.
To an OS or filesystem, that's just a failing drive. You might get lucky and things might work.