In particular, Apple has further tightened its System Integrity Protection process, and is completely denying access to some files on the startup volume, even when copying to a non-startup volume.ĪPFS doesn’t seem to be faster than HFS+ (which is not to say it won’t ever be, or that it won’t be more stable.a low bar, I know).Īpple offers a couple helpful APFS-related knowledgebase articles here:Īpple Kbase HT208018: Prepare for APFS in macOS High SierraĪpple Kbase HT208020: Upgrade macOS on a Mac at your institution And since there might be other APFS volumes in that container, you’d end up destroying them. So, we’d have to convert the container to a regular GUID partition. We’ve designed and implemented that, and it’s significantly different than HFS+’s boot setup, with various special partitions dedicated to specific purposes (even a separate VM volume!), and entire new volume management system, etc.įor example, what happens if you do an “Erase, then copy” from an HFS+ volume to an APFS volume? In our current version, we match the format of the source when we erase. We basically have to make an educated guess about what they want. An example of what they have in mind was released for the very first time when the High Sierra developer release came out a few months ago, but that’s it. But it’s important to note that Apple still hasn’t released any documentation on the “proper” way to create a bootable APFS volume. I know this kind of hedging is disappointing. The bad news is I’m not confident enough to say we’re going to release our APFS support day-and-date.
0 kommentar(er)
