I tried this from the debugger and discovered that URLByResolvingSymlinksInPath
“fixes” the /private/
addition.
(lldb) p (NSURL *)[NSURL fileURLWithPath:@"/private/var" isDirectory:YES]
(NSURL *) $1 = 0x1fd9fc20 @"file://localhost/private/var/"
(lldb) po [$1 URLByResolvingSymlinksInPath]
$2 = 0x1fda0190 file://localhost/var/
(lldb) p (NSURL *)[NSURL fileURLWithPath:@"/var" isDirectory:YES]
(NSURL *) $7 = 0x1fd9fee0 @"file://localhost/var/"
(lldb) po [$7 URLByResolvingSymlinksInPath]
$8 = 0x1fda2f50 file://localhost/var/
as you can see, file://localhost/var
is what we really want here.
Because of this, it seemed obvious that /private/var
is a symlink to /var
.
However, @Kevin-Ballard points out that is not true. I confirmed that he is correct, and /var
is the symlink to /private/var
(sigh)
(lldb) p (NSDictionary *)[[NSFileManager defaultManager] attributesOfItemAtPath:@"/var" error:nil]
(NSDictionary *) $3 = 0x1fda11b0 13 key/value pairs
(lldb) po $3
$3 = 0x1fda11b0 {
...
NSFileType = NSFileTypeSymbolicLink;
}
(lldb) p (NSDictionary *)[[NSFileManager defaultManager] attributesOfItemAtPath:@"/private/var" error:nil]
(NSDictionary *) $5 = 0x1fda4820 14 key/value pairs
(lldb) po $5
$5 = 0x1fda4820 {
...
NSFileType = NSFileTypeDirectory;
}
So URLByResolvingSymlinksInPath
is doing something funny here, but now we know. For this particular problem, URLByResolvingSymlinksInPath
still sounds like a good solution that works for both the simulator and the device and should continue to work in the future if something changes.