Since iOS 10.3.3 was released, we've been seeing more and more reports of users unable to back up their devices because of a recurring disconnection error. Further investigations revealed that the error happens both with iMazing and iTunes, and is the consequence of a subtle bug in iOS 10.3.3's handling of specific non english characters in file names.
We'll first cover how to diagnose and fix the issue, and will then go into a bit more detail into the underlying reasons behind this APFS related bug.
You are affected if all the following statements are true:
Erasing the device completely and restoring from an iCloud backup may take care of the problem, but it is a time consuming procedure which isn't always applicable.
The other solution is to identify the file or files which are causing the bug. To do this, you will need to install iMazing and use its device console while backing up your device. You do not need to purchase a license: the free trial will work just fine.
Aug 7 12:52:05 Greg-iPhone BackupAgent2(CoreFoundation)[328]
: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'No operation found for path: /var/mobile/Containers/Data/Application/9944C65F-F8E5-4CA5-951B-7B6AF0A40D1D/Documents/File-Name-With-Special-Characters'
The path displayed is that of the guilty file. If you can identify in which app it is stored, you can simply rename it in the app in question, directly on your device. Choose a name with english standard characters only to be sure to avoid the bug. At this point, it's also a good idea to rename other potentially problematic files at the same location.
Now, back up again in iMazing, with the Device Console open: if there are any more problematic files, the backup will fail again and you'll need to repeat the procedure.
In the example log above, 9944C65F-F8E5-4CA5-951B-7B6AF0A40D1D is the app's GUID. You can use iMazing's capabilities to export advanced info from your phone to a text file, that text file will contain a list of installed apps along with their GUID.
If you still cannot identify the location of the problematic file on your device, you can contact us and we'll do our best to help! Don't forget to send us the Console log of the error.
Note: the GUID of apps is only exported by iMazing Mac 2.4 upwards, or iMazing Windows 2.3 and upwards. iMazing Windows 2.3 is scheduled for release on the 19th of September, along with iOS 11.
The problem has its roots in APFS, Apple's new file system introduced in iOS 10.3.0. To summarize, some special characters have 2 distinct Unicode representations: the Spanish ñ for example has a precomposed variant (Unicode U+241) and a decomposed variant (Unicode U+110:n and U+771:̃).
Before APFS, it was not possible for 2 filenames which look identical but are encoded with different variants to coexist. The file system was normalization insensitive. On the other hand, in iOS 10.3.0, APFS is normalization sensitive, which led to quite a few issues, some of which we covered at the time here: https://imazing.com/blog/ios-10-3-broke-itunes-file-sharing-on-windows
Now, iOS 10.3.3 is supposed to take care of the issue by re-introducing Unicode normalization of file names:
The bug we describe here only occurs after an upgrade. We hypothesize that runtime normalization is not consistent enough: probably the Backup Agent on the device uses non-normalizing low level POSIX functions to list files, but higher level APIs handling paths and file system operations do normalize, resulting in the crash we notice in the console.
Computer side, Apple Mobile Backup simply detects a disconnection: indeed, it has been disconnected from the crashed backup process iOS side.