Re: Updated APFS guide

Subject: Re: Updated APFS guide
From: Eric Tamura <email@hidden>
Date: Fri, 31 Mar 2017 17:07:41 -0700

On 31 Mar 2017, at 4:55 PM, Thomas Tempelmann <email@hidden> wrote:

On Sat, Apr 1, 2017 at 1:32 AM, Brendan Shanks <email@hidden> 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

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 (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden

References:

>Updated APFS guide (From: Brendan Shanks <email@hidden>)

>Re: Updated APFS guide (From: Thomas Tempelmann <email@hidden>)

Prev by Date: Re: New Disk Utility apparently not using rdisk when saving / restoring partitions

Next by Date: Re: NSURL getResourceValue: for NSURLVolumeMaximumFileSizeKey returns nil

Previous by thread: Re: Updated APFS guide

Index(es):

Date

Thread