undefined | Better HN

0 pointsjjcob8mo ago0 comments

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.

0 comments

nickcw8mo 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

borisgolovnev8mo ago

It's a shame APFS does nothing to ensure file integrity.

j / k navigate · click thread line to collapse