“WriteToFile: atómicamente:” se produce un error en el archivo de Certain ACL

Question

Si tengo un archivo se puede escribir con una ACL-imperio de deny delete, cualquier [plistableObject writeFoFile:undeletableFile atomically:YES] devuelve la llamada NO, mientras que las escrituras no atómicas tienen éxito.

Yo sé, que los medios de escritura atómicas que un archivo temporal fue escrito y - si está escrita con éxito - con el tiempo cambian de nombre. Esta implicación particular de ella siente extraño , sin embargo.
Por eso me pregunto, ¿esto es debido a la ...

1. La falta de un 'cambio de nombre' directa en HFS +,
2. una deficiencia en la ejecución de -[NS(Array|Dictionary|Data|String) writeToFile:atomically:] o
3. una deficiencia en la implementación de ACL en Mac OS X?

Gracias de antemano

Daniel

---

pregunta original:
He encontrado este comportamiento extraño, el otro día en un Mac que restaura a partir de una copia de seguridad:
La mayoría de las aplicaciones no fueron capaces de persistir sus preferencias -. Especialmente Mail.app que advertía con un mensaje de error, lo que sugiere que era incapaz de escribir a ~/Library/Preferences

El cavar más profundo, me encontré con que - de alguna manera - la mayoría de plists tenían una ACL con el group:everyone deny delete Directiva en su lugar; abandonando esta regla salvó el día.

Yo sospechaba NSArray|NSDictionary|NSWhatHaveYou de writeToFile:atomically: ser * responsables de este comportamiento y - efectivamente - la prueba de la herramienta que escribí sólo se logra cuando se pasa NO como el segundo argumento si el archivo existe y tiene una ACL tales en su lugar ...

(*, donde por "responsable" Sólo quiero decir la parte no-escritura; la situación ACL era algo completamente distinto)

Por eso me pregunto:

Es esto un error o una función?

Mientras que - técnicamente - este método escribe un archivo y al terminar le cambia el nombre, desde la perspectiva del usuario no está eliminando cualquier cosa ...

es un error:
En caso de que se presentó contra NSArray y amigos o en contra de la implementación de ACL?

Cualquier pensamiento muy apreciada!

Saludos

Daniel

Answer 1

Después de algo de investigación en la fuente HFS he llegado a la conclusión de que no hay tal cosa como una función rename sistema de archivos nativo en Mac OS.

En su lugar, se implementa como (pseudocódigo)

link!
successful:
   return 0
// otherwise
unlink!
successful:
  link!
  return error_code
// otherwise
return error_code

Así que este comportamiento es de esperar: - (

Dicho esto, no sé lo suficiente sobre cualquiera de los sistemas de ficheros o la programación de bajo nivel para decidir si la creación de un rename nativa valdría la pena la molestia aplicación.

Me fuertemente sensación que sería lo correcto para hacerlo, pero ...

---

Editar

jfortman señaló , un cambio de nombre atómica en realidad sería posible y bastante recta hacia adelante a través del uso de la siguiente secuencia:

1. escritura en archivo temporal
2. exchangedata( path_to_tempfile, path_to_destination_file, options ) (por cierto: la estados página de manual que esta función es de alrededor desde Darwin 1.3.1 / Mac OS X 10.0 ...)
3. tempfile eliminar