writing non-ascii filenames with legacy C functions makes APFS inconsistent with modern filesystem API's

Number:rdar://30684036 Date Originated:23-Feb-2017
Status:Open Resolved:
Product:iOS + SDK Product Version:iOS 10.3 (14E5249d)
Classification:Serious Reproducible:Always
Something not on this list

If you use legacy stdio functions for writing to non-ascii filenames, the filesystem enters a weird state, where NSFileManager can list the file, but checks if it exists fail.

Steps to Reproduce:
1. write "hello" to file named "acentuação.txt" with fopen/fwrite/fclose
2. list files available with NSFileManager contentsOfDirectoryAtPath:error:
3. check if the single listed file exists with NSFileManager fileExistsAtPath:

Expected Results:
the file should exists, since we had it returned by contentsOfDirectoryAtPath:error:

Actual Results:
the file does not exist

iOS 10.3 (14E5249d)

Xcode example has been attached where the error is provoked in application:didFinishLaunchingWithOptions:

Problem seems to happen only on iOS 10.3 no matter what device, as long as it is on device. It does not happen in the simulator.

iPad Air 1, 32GB cellular


[Closed] [DUPLICATE OF 30735074 (OPEN/CLOSED)]

Apple closed the radar marking it as a duplicate of 30735074.

Since the bug is still present, I will keep the status Open on the openradar entry and will return to edit when a actual fix is out.

I agree and somehow the method name shaped my language. Hoping the bug can be understood despite this.

"Actual Results: the file does not exist"

That's not the result. The result is that fileExistsAtPath: claims it doesn't exist.

By marcus.mattsson at March 14, 2017, 10:32 a.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!