What does the /private prefix on an iOS file path indicate?

Question

I have a bug when my app runs on the iPhone but not when it runs on the simulator. I was using the length of the home directory path to extract the relative path of a file

Answer 1

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.