2010-12-13 16 views
0

je copie des données à l'aide NSFileManager:processus d'arrêt NSFileManager

success = [manager copyItemAtPath:[dirToCopyFrom stringByAppendingPathComponent:file] toPath:[dirToCopyTo stringByAppendingPathComponent:file] error:&copyError]; 

NSFileManager semble fournir aucun moyen d'arrêter ce processus cependant. Y a-t-il un moyen?

Merci

Répondre

4

Pas avec NSFileManager, non. Vous devez passer à la fonction de niveau inférieur FSCopyObjectAsync.

Pour un exemple sur l'utilisation de cette fonction, consultez this question. Pour annuler la copie, le premier paramètre que vous allez obtenir pour votre rappel de copie est . Passer ce paramètre comme argument à FSFileOperationCancel() doit annuler la copie. (Voir this CocoaBuilder.com thread for more info)

+0

Je me demande pourquoi Apple n'a pas implémenté cela. – Pripyat

1

Ceci est une question assez ancienne mais je suis tombé dessus parce que j'avais exactement le même problème; Je voulais utiliser les méthodes NSFileManager over Carbon et implémenter une copie récursive manuelle, car il y a trop de cas à gérer, et NSFileManager fait un bon travail de résolution des erreurs dans les opérations de fichiers (par exemple, passer d'un volume à un autre, etc.). Vous pouvez arrêter NSFileManager, essentiellement, en provoquant une erreur. Ce n'est pas joli, mais ça fonctionne correctement. Par exemple. J'ai utilisé NSFileManager pour déplacer un répertoire d'un endroit à un autre, et j'ai donné à l'utilisateur la possibilité d'annuler l'opération; Pour contourner le 'non-annulabilité' de NSFileManager, j'ai juste renommé le répertoire de destination pendant que son contenu est copié; NSFileManager déclenche une erreur et l'opération de copie s'arrête proprement. Cela ne fonctionnera que pour les déplacements entre volumes ou copies, (lorsqu'une copie ou une copie-suppression est effectuée), car pour les déplacements dans un volume, OSX effectue simplement un changement de nom, ce qui est pratiquement instantané.

0

J'ai essayé de déplacer le fichier comme le message précédent l'a suggéré, mais le déplacement n'entraîne pas le retour de copyItemAtURL avec une erreur. Il semble qu'Apple a désapprouvé une méthode qui n'a aucun remplacement avec la fonctionnalité équivalente.