Sauvegarde : création d'un chemin d'accès
odjau
Membre
Salut tout le monde,
je suis actuellement en train de faire les tutoriaux de Projet:Omega, et je me pose la question suivante :
Lorsque je fait une sauvegarde (par exemple les données d'un NS TableVIEW) en utilisant la méthode writeToFile:atomically: je ne suis pas assuré que l'écriture sera faite si l'argument désignant le chemin d'accès ne correspond pas à un chemin déjà existant. Quelle méthode utiliser pour créer le chemin complet s'il n'existe pas ?
Merci d'avance
@+
je suis actuellement en train de faire les tutoriaux de Projet:Omega, et je me pose la question suivante :
Lorsque je fait une sauvegarde (par exemple les données d'un NS TableVIEW) en utilisant la méthode writeToFile:atomically: je ne suis pas assuré que l'écriture sera faite si l'argument désignant le chemin d'accès ne correspond pas à un chemin déjà existant. Quelle méthode utiliser pour créer le chemin complet s'il n'existe pas ?
Merci d'avance
@+
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
if (!(NSFileManager defaultManager] fileExistsAtPath:[[[NSString stringWithString:@"~/Documents/"] stringByExpandingTildeInPath] stringByAppendingPathComponent:[NSString stringWithString:@"MySoftDatas" isDirectory:&repExist] && repExist)) // Est-ce que le répertoire "MySoftDatas" existe dans le répertoire "Documents" ?
  {
    NSFileManager defaultManager] createDirectoryAtPath:[[[NSString stringWithString:@"~/Documents/"] stringByExpandingTildeInPath] stringByAppendingPathComponent:[NSString stringWithString:@"MySoftDatas" attributes:nil]; // Non, alors le créer
  }
J'utilise ce code dans les méthodes init: ou awakeFromNib: pour vérifier l'existence d'un répertoire, et sa création le cas échéant. Ce qui fait qu'il n'y a plus de problèmes pour l'écriture des fichiers ensuite. J'espère que je répond à ta question !
Merci
Tout soft qui se respecte doit normalement incorporer ce chtit bout de code. 8)
Non ? :P
La méthode "fileExistAtPath:" vérifie l'existence d'un fichier et non d'un répertoire. Dans ton code, tu vérifies l'existence du fichier DvdThèque, et s'il n'est pas trouvé, tu crées.......le répertoire DvdThèque. Tu es obligé d'utiliser la méthode "fileExistAtPath:isDirectory:" pour spécifier que tu demandes bien la vérification d'existence d'un répertoire.
Dans la doc Apple, ce n'est pas très clair. Même dans la méthode fileExistsAtPath:isDirectory: la doc parle de file au lieu de directory.
J'ai mis un NSLog pour comprendre le fonctionnement. S'il y a un dossier DvdThèque, fileExistsAtPath: retourne YES, même s'il n'y a pas de fichier DvdThèque. S'il n'y a pas de dossier, ça retourne NO.
Qu'en penses-tu ?
- (BOOL)fileExistsAtPath:(NSString *)path
Returns YES if the file specified in path exists, or NO if it does not. If path specifies a symbolic link, this method traverses the link and returns YES or NO based on the existence of the file at the link destination. If path begins with a tilde, it must first be expanded with stringByExpandingTildeInPath, or this method will return NO.
Sinon un fileExistsAtPath:isDirectory: marche aussi pour les fichiers si tu donne nil à isDirectory....mais bon il n'y a aucune utilité....
Enfin bon c'est curieux cette histoire.... :why?: ;D
Est-ce que file ne désigne pas à la fois un fichier et un dossier ? L'option isDirectory permettant de faire la distinction entre les deux ?
Je reconnais que si un fichier existe, portant le même nom que le dossier recherché, ça va f.. un sacré b..
[EDIT]
En fait, si un fichier DvdThèque existe, l'appli ne crée rien du tout, mais refuse d'enregistrer. Normal.
Bon c'est pas bien grave, mais je vais quand même changer dans mon exemple.
Surtout que j'ai mis "merci Eddy58", et c'est toi qui vas te faire eng.. ;D
le terme file peut recouvrir des tas de choses selon le type de file justement:
ça m'a donné l'occasion de faire fonctionner mon NSLog(@Et toi là haut..);
Stressant, une appli qui ne veut pas quitter !
Je l'ai déjà dit dans un autre post, mais Eddy58 a raison. Il est plus sûr d'ajouter isDirectory.
[EDIT]
Soit j'ai mal recopié, soit il y a un problème.
J'ai laissé mon fichier DvdThèque ; il n'y a pas création d'un dossier DvdThèque.
Manuellement, Finder râle car les deux portent le même nom. Du coup, isDirectory est insuffisant. Si le file existe et n'est pas un dossier, il faut changer le nom du dossier que l'on veut créer. Quel bazar.
Me suis-je trompé en recopiant le code ? Ou est-ce vraiment la ch.. ?
[EDIT]
Je viens d'essayer, j'ai créé un fichier, puis ensuite fais fonctionner la procédure, et bien le répertoire, portant le meme nom que le fichier, se crée sans problème.
Je préfère plutôt ça : :rose!: ok Tiff ?
L'intérêt du isDirectory est de vérifier que DvdThèque est bien un dossier. Mais si c'est autre chose ? Que fait-on ?
Pour l'instant, j'ai viré isDirectory, j'ai viré le fichier DvdT.. et je peaufine mes bindings de menus popup. Ce que je veux, c'est avoir une appli utilisable le plus rapidement possible.
Ca marche bien chez moi......
T'es sur que t'essaies pas de faire fonctionner ça sur Windows pour obtenir un message d'erreur ? ;D
Mais j'ai pris mon fichier DvdThèqueData, que j'ai renommé DvdThèque. Et là , Finder n'en veut pas car "Le nom "DvdThèque" esiste déjà . Veuillez choisir un autre nom."
C'est quoi vindauze ? ???
Volume ejecté
Volume protégé en écriture
Fichier déjà ouvert par une autre appli
Fichier corrompu
Données corrompues
.../... pleins de raisons de mettre un garde fou s'assurant que l'enregistrement a bien eu lieu n'est-ce pas ?
Une parenthèse pour ClicCool : je me suis arraché les cheveux avec les menus popup dans les TableView, jusqu'à ce que je trouve le "bug" de I.B. :
Si une colonne avec des cellules normales (Default Data Cells) est déjà bindée avec Value, lorqu'on lui balance des cellules popup, la colonne se retrouve bindée avec Parameters, sans que l'on s'en rende forcément compte. Bien sûr, l'appli plante systématiquement, jusqu'à ce qu'on débinde (quand je pense à Ferninde) les Parameters. Suis-je clair ? :P
Mon appli DvdThèque est presque opérationnelle, je n'ai plus qu'à ajouter une méthode pour récupérer les données de VidéothèqueData.
Une fois terminé, tout paraà®t si évident !!!
Tu dois normalement pouvoir utiliser une méthode déléguée du callback handler de NSFileManager pour pouvoir déterminer l'erreur non ?
- (BOOL)fileManager:(NSFileManager *)manager shouldProceedAfterError:(NSDictionary *)errorInfo
Je vais essayer d'attendre ce soir pour aller voir ça. ça va être dur de résister à la tentation.
Bande de sadiques ;D
Pour ça tu devrais pouvoir utiliser un NSValidateValue
regardes aussi du coté de copyWithZone peut-être ? ;D :P