3 ms·

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 exam

by 0x0 9y ago

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? :-/

vvhn 9y ago
>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+ ?
- LeoNatan25 9y ago
  It’s a lot more subtle than that. Under certain (very) edge cases, there may be an issue.
- SyneRyder 9y ago
  Yes. There's some details here: https://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenames/ 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."
  - vvhn 9y ago
    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.

by 0x0 9y ago

vvhn 9y ago

>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+ ?

LeoNatan25 9y ago
It’s a lot more subtle than that. Under certain (very) edge cases, there may be an issue.
SyneRyder 9y ago
Yes. There's some details here: https://mjtsai.com/blog/2017/03/24/apfss-bag-of-bytes-filenames/ 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."
- vvhn 9y ago
  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.