iOS Developers: Beware of Long File Paths
No ratings yet.
I try to keep my blogging targeted to customers and the general public, but today I have a very interesting finding to share with iOS developers. (If you stumbled onto this post because you have a corrupt backup, you may find this article more helpful!)
The maximum path length on iOS is currently 1024. Most developers won't create files that hit that limit (yay) but if you're getting close, you will likely end up testing your file's fully-qualified path against the variable PATH_MAX constant in syslimits.h. This is all lovely, and you're filenames will be short enough to fit on the device without issue. However, your customers may hit a big snag when when they try to restore backups in iTunes or via iCloud.
iOS copies all of the files into a temporary directory as part of the restore process. The temporary directory location may have a longer fully-qualified path than the location your file usually resides at during normal operation. This longer location will cause the backup to be reported as corrupt.
The shortest path I've seen break a restore at this point is 932 characters from the root of the application sandbox folder. If we include the typical sandbox folder (another 85 characters), that's 1017. I would highly recommend setting PATH_MAX - 7 (exclusive) as your limit rather than PATH_MAX (exclusive)1.
-
Annoying footnote, for those desperate for long filenames. The 932 limit is actually for a directory, because
lstatsticks the trailing slash on the end, and with the backup container folder, pushes the filename to 1024 characters. That's my way of saying you could probably squeeze one more character into your limit if you're dealing with a file and not a directory name. ↩