CreateFileAtPath & OCUnit & errno blues

Question

J'ai regardé ici et là mais en vain.

Considérez :

- (void) write: (NSString *) xId data:(NSData *) data forClass: (Class) c {
    NSFileManager * fm = [NSFileManager defaultManager] ;

    NSString * instancePath = [self instancePath:xId forClass: c] ;

    errno = 0 ;
    BOOL success = [fm createFileAtPath: instancePath
                               contents: data
                             attributes: nil] ;
    if (!success) {
        ::NSLog(@"Couldn't write to path: %@", instancePath) ;
        ::NSLog(@"Error was code: %d - message: %s", errno, strerror(errno));
    } else {
        ::NSLog(@"COULD write to path: %@", instancePath) ;
        ::NSLog(@"Error was code: %d - message: %s", errno, strerror(errno));
    }
}

Qui affiche alors :

2013-03-22 18:59:27.177 otest[18490:303] COULD write to path: /Users/verec/Library/Application Support/iPhone Simulator/6.1/Documents/cal/ModelRepo/ModelRepo#0.sexp
2013-03-22 18:59:27.177 otest[18490:303] Error was code: 3 - message: No such process
2013-03-22 18:59:27.178 otest[18490:303] Couldn't write to path: /Users/verec/Library/Application Support/iPhone Simulator/6.1/Documents/cal/ModelContainer/20130322.sexp
2013-03-22 18:59:27.178 otest[18490:303] Error was code: 3 - message: No such process

1. Pourquoi errno n'est-il pas égal à 0 même si `success' est YES dans le premier cas (le cas "COULD")?
2. Est-ce que quelqu'un peut repérer la différence dans le chemin réel qui fait que success=YES dans le premier cas ("COULD") mais success=NO dans le second ("Couldn't")?

Ceci est en exécutant un test OCUnit, Xcode 4.6.1 Simulateur fonctionnant sous iOS 6.1

Je suis juste dérouté :-(

Answer 1

• La variable errno n'est généralement définie que par les appels système (et certaines fonctions de bibliothèque) si l'appel a échoué. Elle n'est pas modifiée si un appel système a réussi, et peut contenir une valeur non nulle d'une erreur précédente.

• Il est conseillé d'imprimer ou de sauvegarder immédiatement errno après un appel système échoué. Dans votre cas,

  NSLog(@"Impossible d'écrire dans le chemin : %@", instancePath);

  modifie en fait errno. ("Aucun tel processus" est très peu probable en tant que raison d'échec correcte.)

• Pour la même raison, vous ne pouvez pas supposer que errno contient la valeur correcte après l'échec de createFileAtPath. Cela l'a effectivement fait lors de mon test, mais il n'est pas documenté que cette méthode définit/préserve errno correctement.

Answer 2

Je rédige cette réponse pour aborder le code d'erreur de verec de manière plus détaillée avec un code blob. Il en a en fait fait allusion dans son commentaire sur la réponse acceptée.

L'erreur qu'il a obtenue de createFileAtPath était 3 (ESRCH) - No Such Process

Une raison possible pour cela est que createFileAtPath NE créera PAS les répertoires intermédiaires, donc si un répertoire sur le chemin du chemin que vous souhaitez créer n'existe pas, il échouera avec ce code d'erreur.

Vous devez plutôt utiliser createDirectoryAtPath:withIntermediateDirectories:attributes:error: pour créer d'abord les répertoires, puis utiliser createFileAtPath après avoir créé ceux-ci avec succès.

NSString *fileParentFolderPath;
NSString *filePath;

// Créez d'abord le répertoire, createFileAtPath ne peut pas créer de répertoires intermédiaires
NSError *error;
if([[NSFileManager defaultManager] createDirectoryAtPath:fileParentFolderPath
        withIntermediateDirectories:YES attributes:nil error:&error]) {
    // puis créez le fichier
    if(![[NSFileManager defaultManager] createFileAtPath:filePath 
            contents:nil attributes:nil]) {
        NSLog(@"Échec de la création du fichier, l'erreur était le code : %d - message : %s", errno, strerror(errno));
    };
} else {
    NSLog(@"Échec de la création du répertoire avec l'erreur : %@", error);
};