4 ms·

I tried running the file segments through a binary diff with Hex Fiend As far as I can tell: - 0x7800 bytes were replaced at file offset 0x00aa0000 - 0x2200

by jjcob 1y ago

I tried running the file segments through a binary diff with Hex Fiend As far as I can tell: - 0x7800 bytes were replaced at file offset 0x00aa0000 - 0x2200 bytes were replaced at file offset 0x00aa8000 I can't tell if the replacement data came from a different part of the file, or somewhere totally different. Race condition somewhere sounds plausible.

nickcw 1y ago
gcd(0x2200,0x7800) = 512 So some part of the chain with 512 byte buffer size corrupted the data. It doesn't look like a memory corruption but if this were my computer I'd run the equivalent of memtest86 on it. It looks like a filing system corruption to me. Running `diskutil info` on the main harddisk and the sd card might be interesting to see if the block sizes match. Running a disk tester on the sd card and the main disk might be a good idea too. Here is one I wrote: https://github.com/ncw/stressdisk https://github.com/ncw/stressdisk
- borisgolovnev 1y ago
  It's a shame APFS does nothing to ensure file integrity.