В приложении после обновления iOS 8 OTA от iOS 7 мы заметили, что атрибутыOfItemAtPath показали другое значение для определенного файла, поскольку NSFileProtectionKey удаляется процессом обновления.NSFileProtectionKey удаляется после обновления iOS 8 OTA?
Кто-нибудь еще видит это? Каковы масштабы этих изменений?
Когда App Store загружает обновление, он устанавливается в новый каталог перед перемещением файлов из предыдущей установки. Files inside these application directories are migrated:
Documents
Library
Файлы в других местах, могут или не могут быть перенесены. Ваше приложение не должно полагаться на другие файлы, присутствующие после обновления. Когда iOS обнаруживает условие низкого дискового пространства, он выбирает, какие файлы следует очищать. Файлы в NSCachesDirectory и NSTemporaryDirectory() могут быть очищены. Файлы или каталоги с атрибутом «Не создавать резервные копии» (NSURLIsExcludedFromBackupKey/kCFURLIsExcludedFromBackupKey) не будут очищены, и ваше приложение будет отвечать за их очистку. From the iOS Data Storage Guidelines:
Используйте атрибут «не создавать резервные копии» для указания файлов, которые должны оставаться на устройстве, даже в ситуациях с низким уровнем хранения. Используйте этот атрибут с данными, которые можно воссоздать, но они должны сохраняться даже в ситуациях с низким уровнем хранения для правильной работы вашего приложения или потому, что клиенты ожидают его доступности в автономном режиме. Этот атрибут работает с отмеченными файлами независимо от того, в каком каталоге они находятся, включая каталог «Документы». Эти файлы не будут очищены и не будут включены в пользовательскую iCloud или iTunes. Поскольку эти файлы используют пространство хранения на устройстве, ваше приложение отвечает за мониторинг и очистку этих файлов периодически.
Существует важное замечание по поводу этого атрибута в NSURL.h:
верно, если ресурс должен быть исключен из резервной копии, иначе ложь (чтения-записи, тип значения булева NSNumber). Это свойство полезно только для исключения кеша и других файлов поддержки приложений, которые не нужны в резервной копии. Некоторые операции, обычно выполняемые с документами пользователя, приведут к тому, что это свойство будет сброшено на значение false, и поэтому это свойство не должно использоваться в пользовательских документах.
Если этот атрибут используется в сочетании с NSFileProtectionKey, это может привести к неопределенному поведению. Атрибут резервного копирования считывается и записывается одной подсистемой, а ключ защиты файлов используется другим. Во время обновления или восстановления приложения файл может быть перенесен или восстановлен без сохранения значения сохранения файла. Кроме того, добавление атрибута защиты данных в файл заменит старый файл на защищенный. Это прозрачно для вашего приложения, но может иметь побочный эффект при обновлении или восстановлении, чтобы установить незащищенную версию. Это одна из многих причин, по которой рекомендуется устанавливать этот атрибут всякий раз, когда файл записывается вашим приложением.
Я сделал несколько тестов и заметил, что при низких условиях хранения файлы с NSURLIsExcludedFromBackupKey не очищаются. – Blaze
@ Blaze, вы правы, у меня была логика. В то время, когда я написал это первоначально, соответствующая документация была недоступна. Ответ обновлен. – quellish
Извините, но я не верю, что эти цитаты разъясняют что-то о том, почему 'NSFileProtectionKey' получает сброс. Вторая цитата рассказывает о некоторых _writes_ для _user documents_, вызывающих сброс флага DoNotBackup. Однако в моем случае «NSFileProtectionKey» сбрасывается для файла в разделе «Поддержка библиотек/приложений», которое явно указано в документах. –
Я не верю, что есть какой-либо официальный ответ или документация, которая применяется.
В моем случае файлы под Library/Application Support были установлены на NSFileProtectionComplete после обновления приложения, на iOS 9 и 8.
Это seeems быть вызвано защиты данных, установленным на Закончите на App ID на серверах компании Apple, которая, в свою очередь, кажется были автоматически обновляется с помощью Xcode, когда она регенерируется профили инициализации после обновления сертификата (несмотря на Функция защиты данных отключена в локальном проекте Xcode).
Это на самом деле имеет смысл. iOS безопасно работает и заботится об обновлении защиты данных во всех файлах после включения защиты данных для новой версии.
Что не имеет смысла, так это когда кто-то еще (хем Xcode) решает добавить это право на вас.
вещи, чтобы добавить в контрольный список выпуска:
Является ли это файл или каталог который также имеет атрибут NSURLIsExcludedFromBackupKey? – quellish
Да, это правильно. Как это повлияет на это? – Blaze