Que signifie le préfixe / private sur un path de file iOS?

J'ai un bug quand mon application fonctionne sur l'iPhone mais pas quand elle fonctionne sur le simulateur. J'utilisais la longueur du path du directory personnel pour extraire le path relatif d'un file dans / Documents. Malheureusement, cela ne fonctionne pas toujours correctement sur l'iPhone car le préfixe "/ private" est ajouté au path d'access. Cependant, avec ou sans le préfixe, le même file est référencé ok. Le code suivant illustre cette incohérence. Quel est le but de "/ private" et quand est-il fourni par iOS?

- (IBAction)testHomepath:(id)sender { NSFileManager *fmgr = [NSFileManager defaultManager]; NSSsortingng *homePath = [NSSsortingng ssortingngWithFormat:@"%@/Documents",NSHomeDirectory()]; NSSsortingng *dirPath = [homePath ssortingngByAppendingPathComponent:@"TempDir"]; NSURL *dirURL = [NSURL fileURLWithPath:dirPath]; NSSsortingng *filePath = [dirPath ssortingngByAppendingPathComponent:@"test.jpg"]; [fmgr createDirectoryAtPath:dirPath withIntermediateDirectories:NO atsortingbutes:nil error:nil]; [fmgr createFileAtPath:filePath contents:nil atsortingbutes:nil]; NSArray *keys = [[NSArray alloc] initWithObjects:NSURLNameKey,nil]; NSArray *files = [fmgr contentsOfDirectoryAtURL:dirURL includingPropertiesForKeys:keys options:0 error:nil]; NSURL *f1 = (files.count>0)? [files objectAtIndex:0] : 0; NSURL *f2 = (files.count>1)? [files objectAtIndex:1] : 0; bool b0 = [fmgr fileExistsAtPath:filePath]; bool b1 = [fmgr fileExistsAtPath:f1.path]; bool b2 = [fmgr fileExistsAtPath:f2.path]; NSLog(@"File exists=%d at path:%@",b0,filePath); NSLog(@"File exists=%d at path:%@",b1,f1.path); NSLog(@"File exists=%d at path:%@",b2,f2.path); } 

Ce qui suit est écrit dans le journal lors de l'exécution sur l'iPhone. J'ai espacé manuellement la sortie pour montrer la différence entre les lignes 1 et 2.

 2013-02-20 16:31:26.615 Test1[4059:907] File exists=1 at path: /var/mobile/Applications/558B5D82-ACEB-457D-8A70-E6E00DB3A484/Documents/TempDir/test.jpg 2013-02-20 16:31:26.622 Test1[4059:907] File exists=1 at path:/private/var/mobile/Applications/558B5D82-ACEB-457D-8A70-E6E00DB3A484/Documents/TempDir/test.jpg 2013-02-20 16:31:26.628 Test1[4059:907] File exists=0 at path:(null) 

Ce qui suit est écrit dans le journal lors de l'exécution sur le simulateur (pas de "/ private"):

 2013-02-20 16:50:38.730 Test1[7224:c07] File exists=1 at path:/Users/kenm/Library/Application Support/iPhone Simulator/6.1/Applications/C6FDE177-958C-4BF5-8770-A4D3FBD281F1/Documents/TempDir/test.jpg 2013-02-20 16:50:38.732 Test1[7224:c07] File exists=1 at path:/Users/kenm/Library/Application Support/iPhone Simulator/6.1/Applications/C6FDE177-958C-4BF5-8770-A4D3FBD281F1/Documents/TempDir/.DS_Store 2013-02-20 16:50:38.733 Test1[7224:c07] File exists=1 at path:/Users/kenm/Library/Application Support/iPhone Simulator/6.1/Applications/C6FDE177-958C-4BF5-8770-A4D3FBD281F1/Documents/TempDir/test.jpg 

J'ai essayé ceci à partir du débogueur et URLByResolvingSymlinksInPath découvert que URLByResolvingSymlinksInPath "corrige" l'addition /private/ .

 (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/ 

comme vous pouvez le voir, file://localhost/var est ce que nous voulons vraiment ici.

Pour cette raison, il semble évident que /private/var est un lien symbolique vers /var . Cependant, @ Kevin-Ballard souligne que ce n'est pas vrai. J'ai confirmé qu'il est correct, et /var est le lien symbolique vers /private/var (sigh)

 (lldb) p (NSDictionary *)[[NSFileManager defaultManager] atsortingbutesOfItemAtPath:@"/var" error:nil] (NSDictionary *) $3 = 0x1fda11b0 13 key/value pairs (lldb) po $3 $3 = 0x1fda11b0 { ... NSFileType = NSFileTypeSymbolicLink; } (lldb) p (NSDictionary *)[[NSFileManager defaultManager] atsortingbutesOfItemAtPath:@"/private/var" error:nil] (NSDictionary *) $5 = 0x1fda4820 14 key/value pairs (lldb) po $5 $5 = 0x1fda4820 { ... NSFileType = NSFileTypeDirectory; } 

Donc URLByResolvingSymlinksInPath fait quelque chose de drôle ici, mais maintenant nous le soaps. Pour ce problème particulier, URLByResolvingSymlinksInPath ressemble toujours à une bonne solution qui fonctionne à la fois pour le simulateur et le périphérique et devrait continuer à fonctionner dans le futur si quelque chose change.

Pour réellement répondre à votre question:

Je crois que /private était un préfixe ajouté quand ils ont publié OS X (je ne pense pas qu'il était là dans NeXTStep, mais ça fait des décennies ). Il semble exister pour loger etc , var , et tmp (et, bizarrement, tftpboot , je ne savais pas que mon PBG4 pourrait faire cela), peut-être que les users ne se requestnt pas ce que ce dossier idiot appelé etc est et essayez de le supprimer .

Sur l'appareil, Apple a décidé de stocker datatables user dans /private/var/mobile (le nom d'user est "mobile"). Je ne sais pas pourquoi ils n'ont pas choisi /Users/mobile ou simplement /mobile , mais cela n'a pas plus d'importance que /var/mobile sur un Unix "normal".

Sur le simulateur, votre count user ne peut pas écrire dans /var (pour une bonne raison). Les données user sont stockées quelque part dans ~/Library/Application Support/iPhone Simulator . À un moment donné, ils ont commencé à utiliser différents directorys pour différentes versions de simulateurs.

Dans Swift 3, l' URL a la propriété standardizedFileUrl , qui va supprimer tous les liens symboliques et résoudre les parties relatives dans le path comme ./ .

Au moment d'écrire la documentation, cela ne sert à rien, mais on dirait que c'est équivalent à la propriété standardized NSURL.

/var est juste un lien symbolique vers /private/var . Ainsi, le premier path est le path logique auquel vous avez essayé d'accéder. La seconde est le même path avec les liens symboliques développés.