"writeToFile:atomically:" не удается выполнить файл с определенным списком ACL

Question

Если у меня есть доступный для записи файл с ACL-правилом deny delete, любой [plistableObject writeFoFile:undeletableFile atomically:YES] возврат звонка NOтогда как неатомарные записи успешны.

Я знаю, что атомарная запись означает, что временный файл записывается и - при успешной записи - в конце концов переименовывается. Этот конкретный смысл это кажется странным, хотя.
Интересно, это из-за...

1. отсутствие прямого переименования в HFS+,
2. недостаток в реализации -[NS(Array|Dictionary|Data|String) writeToFile:atomically:] или же
3. недостаток в реализации ACL в Mac OS X?

Заранее спасибо

Даниил

---

Оригинальный вопрос:
Такое странное поведение я обнаружил на днях на Mac, который я восстановил из резервной копии:
Большинство приложений не смогли сохранить свои предпочтения - особенно Mail.app, который предупреждал с сообщением об ошибке, предполагая, что он не мог писать в ~/Library/Preferences,

Копая глубже, я обнаружил, что - так или иначе - большинство списков было ACL с директивой group:everyone deny delete на месте; Отказ от этого правила спас день.

Я подозревал NSArray|NSDictionary|NSWhatHaveYou"s writeToFile:atomically: быть ответственным * за это поведение и - конечно же - тестовый инструмент, который я написал, будет успешным только после прохождения NO в качестве второго аргумента, если файл существует и имеет такой ACL на месте...

(* где под "ответственным" я подразумеваю только неписаную часть; ситуация с ACL была совсем другой)

Так что мне интересно

Это ошибка или особенность?

Хотя - технически - этот метод записывает файл и после завершения переименовывает его, с точки зрения пользователя он ничего не удаляет...

Если это ошибка:
Должно ли оно быть подано против NSArray и друзей или против реализации ACL?

Любые мысли высоко ценится!

ура

Даниил

Answer 1

После некоторых поисков в HFS-источнике я пришел к выводу, что нет такой вещи, как родная файловая система rename функция в Mac OS.

Вместо этого он реализован как (псевдокод)

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

Так что такого поведения следует ожидать:-(

Тем не менее, я не знаю достаточно ни о файловых системах, ни о низкоуровневом программировании, чтобы решить, стоит ли создавать нативное rename будет стоить хлопот, реализующих это.

Я чувствую, что это было бы правильно, но...

---

редактировать

Как указал jfortman, атомное переименование было бы действительно возможным и довольно простым благодаря следующей последовательности:

1. написать в tempfile
2. exchangedata( path_to_tempfile, path_to_destination_file, options ) (кстати: на man-странице говорится, что эта функция существует начиная с Darwin 1.3.1/Mac OS X 10.0...)
3. удалить временный файл