Interestingly, the changelogs are silent about a fairly major change to the filesystem when going from 10.3.x to 10.3.3. It seems like APFS was originally intended to use a different unicode normalization setup than HFS, but it turned out to be very problematic. 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, earlier iOS 10.x.x releases did the same dry-run conversion without notice - only stopping short of committing the final type flip - which may explain why iOS OTA upgrades have been somewhat slow to execute - https://www.macobserver.com/analysis/apple-dry-run-apfs-prio... ), iOS 10.3.3 adds runtime normalization to the file system. It's unclear what kind of performance hit this has (but I seem to remember reading something about how samba on UNIX taking a hit on file opens in order to support clients specifying incorrect casing, which sounds similar). Apparently an unspecified later version of iOS will perform yet another conversion, from APFS-normalization-preserving to APFS-native-normalization.
By the way, if you ever rsync between macOS and Linux you may have noticed (or not) how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping, see https://serverfault.com/questions/397420/converting-utf-8-nf...
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.
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.
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.
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+ ?
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.
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 :)
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.
>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 ?
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.
I normally shrug off security vulnerabilities in iOS. But so many in such a minor release?
I know it's not a valid extrapolation ... but if there are so many being fixed just today, that means there are hundreds if not thousands of still undiscovered ones remaining.
This is Microsoft's patch covering ShadowBrokers-leaked ETERNALBLUE SMB remote code execution 0day. The iOS 10.3.3 is likely the response to either the CIA Vault7 Wikileaks stash or the ShadowBrokers NSA EquationGroup stash. These exploits are probably out there in the hands of many people, and Apple had to respond.
They still haven't addressed the permanent website data bug in Safari.
Go to Settings> Safari> Advanced> Website Data and try and clear it. Some websites won't delete arbitrarily, and if they do, others will stick. This happens even in private browsing.
In my experience, those are about as useful as telling your dog about the bug. Complaining on HN has a slight possibility someone from Apple might actually see the bug, and fix it.
I'd disagree, I've filed probably 15 in the past 7 years for obscure bugs and all of them were fixed. They don't respond and the fixes take a long time, but I'm pretty sure they are listening.
Not that this will instil a huge amount of confidence, but I filed a bug about a XNU kernel syscal that returned the wrong error code. They shipped a fix two years later and closer the ticket.
If it was just changing a constant (which is what GP implied), that would probably not constitute sufficient creative output to be subject to copyright.
I would be more inclined to file them if I didn't have to consult an independent third party (open radar) to (hopefully) see what's going on with the radar referenced when one gets closed as a dupe. The more you make it a chore to file or track bugs the less likely I am to bother.
I'm still perplexed that Apple doesn't offer over the air updates, especially for security updates. 137 MB shouldn't be that big a deal on a normal 4G connection.
>137 MB shouldn't be that big a deal on a normal 4G connection.
"I can download a 137MB file when I want over a 4G connection when I want" does not equal "The entire 4G network can handle the high coincident demand of all iPhone users downloading 137MBs simultaneously"
That would be absolute madness. Can you imaging Apple pushing a 137MB file to all active iOS devices over cellular? I'm sure the carriers would appreciate :)
Agreed, this is super annoying. You can install dozens of 99MB apps over 4G every day but nooo you can't have your broadpwn fix on the move. Except if you happen to have two devices with 4G, then you can wifi-hotspot-tether one to the other and vice versa for the update just fine.
But that should be up to the users to decide. I'll be much happier to use up 137 MB for a critical security update than 354 MB for the latest Facebook app update (version 132.0).
Hmm, interesting. Updates, and especially security updates, can be seen as a common good. It's the only kind of thing I can think of that exemptions from data caps might be a good idea for.
I wish there were a cellular broadcast mechanism for data like this. Sending out OS updates, cache prefill, etc. to everyone on a cell network during low use periods would be interesting.
This is what I'm interested in, and I saw that Apple fixed the exploit enabling attackers to own the WiFi chip. What I want to know, does owning the WiFi chip on machines not having the patch provide a beachhead to exploiting the iOS kernel. And if so, are there known active exploits at that level?
More details: https://mjtsai.com/blog/2017/06/27/apfs-native-normalization...
By the way, if you ever rsync between macOS and Linux you may have noticed (or not) how this unicode normalization messes up filenames and cause duplicates and stale copies when roundtripping, see https://serverfault.com/questions/397420/converting-utf-8-nf...
..
Also, unrelated, it seems this version of iOS fixes the Broadpwn wifi chip vulnerability (which perhaps could also continue on to compromise the main OS kernel via a DMA attack after compromising the wifi chip) ( http://boosterok.com/blog/broadpwn2/ , https://nvd.nist.gov/vuln/detail/CVE-2017-9417 )