eafer
commented
2 weeks ago For filesystems with very simple features (case-sensitive, no snapshots, etc), the driver has been tested to death, and I don't expect normal users to suffer corruption. The problem is that you have a lot of possible combinations of feature and mount flags, plus a lot of only partially documented or reverse-engineered record flags (and xfields I think) that keep piling up. I like to think that I've been careful, but I have no way to cover everything in my tests, and some of it may be broken in some unexpected way. The farther your filesystem is from the ones I usually test on, the bigger the risk.
99.99% of users would be fine I think, but the remaining 0.01% would want to murder me for eating their data, hence the mount restrictions (I can't expect everyone to check the readme ahead of time). I should probably tone down the warnings though, it's a bit of an exaggeration at this point. As a packager, if you are willing to explain this to your users and take responsibility, then you can just patch the driver to always set the READWRITE flag unconditionally, putting a line like nx_flags |= APFS_READWRITE; early on parse_options(), for example. I guess I could add some build option for this if you prefer.
kurtbahartr
So I've had one of the leaders at Pisi Linux request a kernel module to mount and recover data from his APFS drive inside the distro. I quickly packaged this kernel module and sent it his way, also noting that RW support is still experimental and noted to corrupt the filesystem in question. He then returned to me with the confirmation that the RW operations he did so far using this module worked just fine and that he could still keep using his macOS installation in it. The testing method we went through is as follows;
sudo mount -o rw,remount /path/to/mntpntNow, here's the question: How experimental is the RW support? How necessary is it to keep it RO-by-default and what would you suggest me to do for offering an easy way to enable RW as a packager?