Maybe I've just missed something in the documentation, but I can't find anything that says this behavior should have changed in iOS 8.
My app sets the current working directory to the Documents
directory, then tries to create a file there using NSFileManager -createFileAtPath
. Prior to iOS 8 this works fine. On devices running iOS 8, I get the following on the call to -createFileAtPath:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException',
reason: '*** -[NSFileManager fileSystemRepresentationWithPath:]: nil or empty path argument'
Here is a minimal code snippet that reproduces the problem:
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *docsDir = [paths objectAtIndex:0];
[[NSFileManager defaultManager] changeCurrentDirectoryPath:docsDir];
[[NSFileManager defaultManager] createFileAtPath:@"temp.dat" contents:nil attributes:nil];
Note the path argument on createFileAtPath
is "temp.dat"
- if I change it to "./temp.dat"
, the call succeeds.
Am I doing something stupid and this was just "accidentally" working in prior iOS releases? Or did they intentionally change the behavior here? Or is this a bug in iOS 8? Other NSFileManager methods that take a path
argument seem to be okay with just a filename (e.g. -removeItemAtPath:@"temp.dat" error:&err
succeeds).
Edited to add:
This only happens on a physical device. In the simulator, the above call to createFileAtPath
succeeds.
I opened a bug with Apple and they closed it as a duplicate. While that doesn't necessarily confirm that they consider it a bug, it at least confirms that I'm not the first to encounter this, and that the behavior did indeed change with iOS 8.
For now, the solution is to prepend ./
to the filename, or supply an absolute path.