Open Radar

 
Summary:
In the latest iOS 12 beta some Korean filenames (거짓말 for example) are not properly handled by NSFileManager even though URL based calls are used.

I need to use POSIX calls to create a file with encoding such that the bug is provoked, but the bug/inconsistency happens entirely in calls to NSFileManager and the example uses NSURL based filenames as is best practice.

The same code runs without problems on iOS 11 devices.

Steps to Reproduce:
1. create file with Korean filename using Posix API's to fully control filename encoding.

2. list directory where we just created file using NSFileManager's contentsOfDirectoryAtURL: includingPropertiesForKeys:options:error:

3. confirm that the written file exists

4. delete the file using NSFileManager's removeItemAtURL:error:

Expected Results:
file should be deleted

Actual Results:
file isn't deleted with message:

Unable to delete file: file:///private/var/mobile/Containers/Data/Application/7FBABD52-BB92-4A3B-AB6C-EE79C7A023D2/Documents/%EA%B1%B0%EC%A7%93%EB%A7%90
Error Domain=NSCocoaErrorDomain Code=4 UserInfo={NSFilePath=<redacted>, NSUserStringVariant=<redacted>, NSUnderlyingError=0x280af1ad0 {Error Domain=NSPOSIXErrorDomain Code=2}}

It is then possible to delete the file using the POSIX call 'unlock'

Version:
iOS 12.0 (16A5318d)

Notes:
The following code provokes the bug by first writing a Korean filename using POSIX style API's. This is preparation of the bug. 

My bug report is about the behaviour of NSFileManager given a filesystem where such a file exists.

Xcode project has been included where this code runs in application:didFinishLaunchingWithOptions.

https://workingcopyapp.com/downloads/DeleteTest.zip