Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I learned about APFS's unreliability the hard way when a friend's Mac started kernel panicking after an upgrade to Catalina... I ended up having to copy file-wise with (a modern version of) rsync from another install to an HFS volume, then manually recreate the entire APFS volume structure, restore everything, and run some obscure commands to make it all bootable again. I was lucky all the files were still readable without the OS panicking; presumably it was a write operation that failed. fsck was completely useless and could not fix the problem.

The rsync mostly preserved all the obscure Mac-specific attributes (resource fork, etc), but at least one thing was lost: the "bundle bit" on directories. Thankfully most bundles are marked another way these days, so only a few things broke (in particular some VST plug-ins, but not others). Good luck finding documentation on that bit! As far as I can tell very few people know of its existence.

The kernel panic was an assert(), which is just inexcusable. FS corruption ("impossible" things in the FS driver) should absolutely never cause the OS to panic. If something fails, return an error to userspace, and possibly remount the filesystem read-only.



If things are unexpectedly broken you don’t want to continue making the system worse by executing transactions against the drive


I didn't know Resource Forks was a think on modern macOS anymore.


They are, although nothing modern uses them and they're mostly just sugar for an extended attribute (the resource fork contents are stored as the value of the attribute "com.apple.ResourceFork"). Mostly, but not entirely: search the APFS documentation[1] for "resource fork" and you'll find inode flags specific to them.

[1] https://developer.apple.com/support/downloads/Apple-File-Sys...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: