restaurarse - ha ocurrido un problema al descargar el software para el iphone

replaceItemAtURL falla sin error en iOS pero funciona bien en OSX

Question

Estoy implementando un proceso de migración desencadenado manualmente para una aplicación basada en CoreData, y después de que la migración se complete con éxito, estoy tratando de mover la base de datos migrada a la parte superior de la original utilizando replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:

El problema es que en iOS, nada de lo que haga hará que este método vuelva a SÍ, sin embargo, nunca coloca nada en el puntero de error para permitirle ver qué está mal.

Leí cosas en otra parte (por ejemplo, http://www.cocoabuilder.com/archive/cocoa/287790-nsdoc-magic-file-watcher-ruins-core-data-migration.html ) indicando que no se están cerrando todos los CoreData Los objetos (por ejemplo, NSMigrationManager, NSManagedObjectModel, etc.) antes de intentar la sustitución pueden ser la causa, pero no fue así. Incluso implementé un pequeño archivo de creación e intercambio de dos cosas que no involucraba CoreData DBs en absoluto para verificar que las cosas de CoreData no tuvieran nada que ver con eso.

Luego noté en la documentación oficial que se supone que el newitemURL está en un directorio que se considera apropiado para los archivos temporales. Supuse que eso significaba un directorio devuelto por URLForDirectory:inDomain:appropriateForURL:create:error: utilizando NSItemReplacementDirectory como la ruta de búsqueda.

¡Eso tampoco funcionó! Terminé recurriendo a la implementación de la lógica de reemplazo mediante operaciones separadas, pero esto no es atómico e inseguro y todo eso es malo.

¿Alguien tiene un fragmento de código de trabajo que se ejecuta en iOS que devuelve SÍ de una llamada a replaceItemAtURL o en realidad coloca información de error en el puntero de error?

Cualquier ayuda muy apreciada.

EDITAR - Código de prueba incluido a continuación. Esto se ejecuta en la application:didFinishLaunchingWithOptions: en el hilo principal.

NSFileManager *fm = [[NSFileManager alloc] init];
NSError *err = nil;
NSURL *docDir = [NSURL fileURLWithPath:[self applicationDocumentsDirectory]];
NSURL *tmpDir = [fm URLForDirectory:NSItemReplacementDirectory
inDomain:NSUserDomainMask
appropriateForURL:docDir
create:NO
error:&err];
NSURL *u1 = [docDir URLByAppendingPathComponent:@"f1"];
NSURL *u2 = [tmpDir URLByAppendingPathComponent:@"f2"];
NSURL *repl = nil;
[fm createFileAtPath:[u1 path]
contents:[[NSString stringWithString:@"Hello"]
dataUsingEncoding:NSUTF8StringEncoding]
attributes:nil];
[fm createFileAtPath:[u2 path]
contents:[[NSString stringWithString:@"World"]
dataUsingEncoding:NSUTF8StringEncoding]
attributes:nil];
BOOL test = [fm replaceItemAtURL:u1 withItemAtURL:u2 backupItemName:@"f1backup"
options:0 resultingItemURL:&repl error:&err];
// At this point GDB shows test to be NO but error is still nil

Answer 1

En el sistema de archivos mac no se distingue entre mayúsculas y minúsculas, sino en IOS. Aunque no puede tener dos archivos con el mismo nombre pero con un caso diferente en una ubicación, la ruta distingue entre mayúsculas y minúsculas. Entonces, si el archivo tiene .JPEG y en su código está pasando el enlace con .jpeg, fallará. Puede que no sea el caso con usted, sino simplemente qué compartir

Aunque extrañamente debería darte un error.

Answer 2

He experimentado problemas con todos los métodos de NSFileManager usando una URL en iOS. Sin embargo, todos los métodos que usan Path funcionan. Así que creo que deberías usar removeItemAtPath:error: y copyItemAtPath:toURL:error: para ese propósito.

Espero eso ayude