Hacker News Reader

> After iOS 10.3.0 silently converted all iOS devices from HFS to APFS (!) (and not only was this not specified in the user-visible changelogs

Are you suggesting Apple didn't disclose APFS was coming to 10.3? There was plenty of media coverage ahead of time (e.g. https://9to5mac.com/2017/03/21/what-is-apples-upcoming-apfs-...), and it's specifically mentioned in the 10.3 release notes.

It was absolutely disclosed all over, so I'm not sure if this is simply the commentor being wrong (most likely) or a weak jab at Apple.

https://developer.apple.com/library/content/releasenotes/Gen...

Those release notes are intended for their developer audience, not the general end user base. Parent was pointing out that the actual release notes Apple shows you on the device you're about to upgrade did not mention APFS.

The general audience doesn't even know that its phone has a file system, let alone care whether it's HFS, HPFS, APFS, or CP/M. You're complaining that Apple didn't disclose something that only developers care about to the masses.

Then at least we can agree that a fairly major operation such as converting the entire disk between file systems in a "minor" update wasn't disclosed to the masses, and I think that fact (and that it worked out quite well, apparently, besides the normalization shenanigans) is interesting it its own right.

I think it's important to distinguish a major change from an impactful one. The APFS change is major, but not necessarily impactful in any meaningful sense to users. Apple's not the kind of company that's going to emphasize non-impactful changes to its customer base.

I'm not sure I agree with that, obviously this seems to cause trouble if you have file names with non-ascii characters in them already, and who knows what else could have gone awry. But let's agree to disagree in that case :)

0x0 (since this thread has hit the reply depth limit): The filesystem on iOS isn’t exposed to users, so I would guess that Apple considers it a strictly developer-facing change.

That's not necessarily true. It's easy to build an app where you prompt for the user's text input to construct a filename for saving a document/picture for example. NSDocumentDirectory is very much still the recommended place to store persistent user data on iOS. Imagine any non-English speaking person entering a non-ascii name for their document.

As another example, imagine Dropbox.app syncing files from the dropbox cloud reusing explicit filenames into the app's sandboxed Application Support/Library/Documents folders. I have no if they do this but if they do this could spell trouble.

Or simply any app supporting iTunes File Sharing, allowing users to drag files from their mac into the app container's NSDocumentDirectory directly.

Edit: Interested in hearing counterarguments instead of downvotes, thanks? :-/

>Imagine any non-English speaking person entering a non-ascii name for their document

You mean there are people in Europe, China, Japan, India running into widespread problems when they create filenames in their own language in iOS 10.3+ ?

It’s a lot more subtle than that. Under certain (very) edge cases, there may be an issue.

Yes. There's some details here:

https://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filena...

The clearest explanation is in one of the updates on that page:

"The most obvious problems arose with iOS users who transferred files from Windows (which prefers a different normalisation form to HFS+) which were named using Korean and other character sets, although this even included European languages with accented characters like ñ and é. There’s a chilling series of messages on the Apple Developer Forums in which an iOS app developer details how users running iOS 10.3 were transferring files using iTunes for Windows, but could not access those files once they were on an iOS device."

The "chilling series of messages" takes you to a link which details how File sharing through iTunes on Windows specifically was affected and that a similar file transfer product on Windows iMazing was able to fix to fix it by simply normalizing before transferring. ( The "bag of bytes" response from Apple asks developers to do exactly that btw )

That begs the question that why iTunes itself ( on Windows ) wasn't able to do the same thing as iMazing ?

Anyway that's moot now - As mentioned earlier in this thread iOS 10.3.3 and iOS 11 are changing behaviour w.r.t. this.

What do you mean by reply depth limit? I'm able to reply to your comment... :-/

To stop flame wars (or slow them down) the deeper you get in a thread the longer it takes the reply link to show on the deepest comment. So if we get 20 levels deep in 30 minutes, the reply link may take tens of minutes to show up.

Sometimes this catches other discussion types.

It's worth pointing out that you can always reply to a comment on its own page, regardless of whether the reply link exists in the main thread.

Indeed, just click the "1 hour ago" link.

That's what was confusing me as that's how I replied. Good info all around. :)

I don't think it was mentioned anywhere in the end-user facing "software update" changelog - if this is the right source https://support.apple.com/kb/DL1893?locale=en_US - but you are right that it was mentioned in the developer SDK release notes https://developer.apple.com/library/content/releasenotes/Gen...

This makes sense to me - why would the user care what kind of filesystem their phones have - developers might - but when you cant choose the filesystem anyhow, what does it matter if the default changes.

> By the way, if you ever rsync between macOS and Linux...

Syncthing handles this with automatic normalization: https://docs.syncthing.net/advanced/folder-autonormalize.htm...

>from APFS-normalization-preserving to APFS-native-normalization.

The developer documentation at [1]

seems to suggest that "native" normalization is normalization preserving as well and that native normalization is based on storing the hash of the normalized name instead of storing the normalized name itself.

" and preserves both case and normalization of the filename on disk in all variants. "

and

" APFS preserves the normalization of the filename and uses hashes of the normalized form of the filename to provide normalization insensitivity, whereas HFS+ stores the normalized form of the filename on disk to provide normalization insensitivity. "

edit - Even the linked blog post says the same thing

" macOS 10.13 will also support case-sensitive APFS, which will use native normalization. This is new in the developer beta. The filenames are still stored in the same way as prior APFS (not normalized like with HFS+), but APFS now uses normalization-insensitive hashes ... "

>how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping

Being normalization preserving should fix that, right ?

1 https://developer.apple.com/library/content/documentation/Fi...

I wonder if the change to the filesystem is why my phones performance feels so sucky the last few months. I have an iPhone 6. it starting hanging for several seconds at various times. It didn't used to suck this much.

Most reports say it's faster, the experience on my iPhone SE has certainly been just fine. I would consider backing up, wiping, and restoring from backup perhaps.