UIDocumentInteractionController NSURL and latin characters

Question

mgarcia OP

Created Apr ’17

Replies 5

Boosts 0

Views 2.0k

Participants 2

Hello,

I am using UIDocumentInteractionController to share custom documents from my app.

When prodividing an URL to a local file path containing characters with accents, it will failed right after the user choose a sharing option.

This problem happens on 10.3, but works perfectly in iOS 9.3.5.

My app is mainly written in C++14, and uses UTF-8 encoding for strings.

I do the following:

NSURL* fileURL = [NSURL fileURLWithPath:[NSString stringWithUTF8String:rPath.GetChars()] isDirectory:!rPath.IsLeaf()];
mpDocController = [UIDocumentInteractionController interactionControllerWithURL:fileURL];

Which gives this error, after a sharing method/option is selected (for example, e-mail):

Couldn't get file size for file:///var/mobile/Containers/Data/Application/FEEF7EA0-E4C5-4EC0-9A03-BB4BFF169729/Documents/Sessions/lo%CC%8
2o%CC%88o%CC%84%C5%93o%CC%83l/lo%CC%82o%CC%88o%CC%84%C5%93o%CC%83l.bm3: Error Domain=NSCocoaErrorDomain Code=260 
"The file “lôöōœõl.bm3” couldn’t be opened because there is no such file." 
UserInfo={NSURL=file:///var/mobile/Containers/Data/Application/FEEF7EA0-E4C5-4EC0-9A03-BB4BFF169729/Documents/
Sessions/lo%CC%82o%CC%88o%CC%84%C5%93o%CC%83l/lo%CC%82o%CC%88o%CC%84%C5%93o%CC%83l.bm3,
SFilePath=/var/mobile/Containers/Data/Application/FEEF7EA0-E4C5-4EC0-9A03-BB4BFF169729/Documents/S
essions/lôöōœõl/lôöōœõl.bm3,

If the path contains any characters with accents, it will fail. However, with regular characters it works fine.

I have tried multiple things, like escaping the NSString before creating the NSURL but I get the same results.

The 'GetChars()' method will return a UTF8 const char*. The path is valid, the file exists and can be read without any problem.

Is this a known 10.3.x or 10.x.x issue?

Any help would be greatly appreciated.

Thank you,

Mathieu.

Boost

Answer 1

QuinceyMorris OP

Apr ’17

I believe you've run into the normalization problem with APFS (the new Apple file system introduced in 10.3) described here:

https://forums.developer.apple.com/message/221440

You can also look here:

developer.apple.com/library/content/documentation/FileManagement/Conceptual/APFS_Guide/FAQ/FAQ.html

in the section "Frequently Asked Questions" -> "Implementation" -> "How does Apple File System handle filenames?".

There are two issues to be concerned about:

1. In some cases you will need to manually normalize a filename string (using "fileSystemRepresentation") before passing it to a system API or library function.

2. There appear to be some bugs regarding normalization in the NSFileManager and NSURL APIs (as discussed in the thread linked above).

It's hard to know at this point exactly which of these is affecting your code. It might be, for example, that you created the file with an unnormalized name, which is going to make it inaccessible via NSFileManager.

You should definitely file a bug report, so that Apple has another example of APFS breaking existing code. If you're lucky, they might suggest a workaround that you can use in the short term.

0

Answer 2

mgarcia OP

Apr ’17

Hello and thank you for your prompt reply.

It does seem to be an APFS issue; I was able to test the same code on 10.2 and it works flawlessly.

I'll keep this thread updated if I find a workaround but I will report a bug report anyway.

Cheers,

Mathieu.

0

Answer 3

mgarcia OP

Apr ’17

After reading the thread you linked to, and trying more things, I still cannot get this to work.

As suggested, I tried avoiding NSString totally which would break normalization of files.

So I tried the following:

NSURL* fileURL = [[NSURL alloc] initFileURLWithFileSystemRepresentation:rPath.GetChars() isDirectory:NO
relativeToURL:nil];

Which give the same results, after the user chose the sharing option: (in this case, e-mail):

[General] #Attachments Error confirming URL is readable [file:///var/mobile/Containers/Data/Application/1F6C378D-6335-4B0C-991D-27030D87CAAB/Documents/
Sessions/l%C3%B4%C3%B6%C5%8D%C5%93%C3%B5l/l%C3%B4%C3%B6%C5%8D%C5%93%C3%B5l.bm3]

I am starting to run out of options and consider just waiting if 10.3.2 will fix the issue.

EDIT: I installed 10.3.2 beta #3 on my iPad Pro and still encountering the same issue.

Cheers,

Mathieu.

0

Answer 4

QuinceyMorris OP

Apr ’17

The problem may be that the file was initially created with a non-normalized file name, which means that your URL with the "correct" normalization won't find it. If you want to diagnose what's going on, you'll need to write some test code that enumerates all of the files in the directory containing your local file, and dumps the raw representation of the file name. (You might need to do this with POSIX I/O functions, to avoid any clever things that the File Manager does to file name strings.) Then compare this with the path string retrieved from your URL. You can then compare string representations manually to see where the mismatch is.

In other words, there's a bit of work involved in trying to solve this yourself.

0

Answer 5

mgarcia OP

Apr ’17

Hello,

I ran some more tests and found something new.

With the same file-name, on an iPad 4th generation (32-bits), with iOS 10.3.1, sharing via e-mail works perfectly.

The same file-name, on an iPad Pro 12.9" (64-bits) with iOS 10.3.2 beta #3 fails with the aforementionned error(s).

I will manually compare the two strings as you suggest to see what comes up, but I feel part of the problem is in

the actual implementation of APFS.

Mathieu.

0