> On 31 Mar 2017, at 4:55 PM, Thomas Tempelmann <tempelm...@gmail.com> wrote: > > On Sat, Apr 1, 2017 at 1:32 AM, Brendan Shanks <bren...@bslabs.net > <mailto:bren...@bslabs.net>> wrote: > The Apple File System Guide was updated yesterday with additional info about > filenames, iOS 10.3, and macOS 10.12.4. Quick summary: no normalization, iOS > 10.3 is case-sensitive, 10.12.4 now has (beta) case-insensitive AFPS. > > https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html > > <https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html> > > > Thanks for the pointer. > > I have trouble understanding this line: > > The case-insensitive variant of APFS is normalization-preserving, but not > normalization-sensitive." > > I assume this is the mode that we now have in iOS 10.3.
No, as indicated in the document, iOS 10.3 uses the case-sensitive variant. The first developer preview of APFS, made available in macOS Sierra in June 2016, offered only the case-sensitive variant. In macOS 10.12.4, the APFS developer preview was updated to also include a case-insensitive variant. In iOS 10.3, the case-sensitive variant of APFS is used. > I ask myself: What is meant by "sensitive" here? I know about > case-sensitivity. There, on a non-case-sensitive HFS system, I can pass names > in any case and they'll all be matched up with the same file name stored > on-disk. Right? > > So, analogously, to my understanding, if I use AFPS on iOS, which is > non-normalization-sensitive, wouldn't it mean that I can pass differently > normalized (e.g. composited and decomposited) names to the FS API, and they > would all match the same file name on disk? No — the APFS version used in iOS is normalization sensitive. One cannot manipulate filenames in user land, then expect to pass the filenames back into the kernel and have the path lookup code work properly (e.g. open(2) and other path based BSD APIs). The documentation explains this. > > However, that contradicts this part from the same article, doesn't it: > > For example, attempting to create a file using one normalization behavior and > opening that file using another normalization behavior may result in ENOENT > > Could someone tell me where my error in this logic is? > > Thomas > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/filesystem-dev/etamura%40apple.com > > This email sent to etam...@apple.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
