Сохраняют ли ZIP-файлы все функции HFS + при создании с помощью команды Finder Compress?

Является ли хорошей идеей сделать резервную копию каталога в файловой системе HFS + с помощью функции сжатия в Finder, а затем скопировать ZIP-файл на жесткий диск FAT32 или в Dropbox и т. Д.? Или это может привести к повреждению или потере данных?

Например, если я сжимаю свою библиотеку iTunes, а символические ссылки заменяются другой копией файла, это изменение в семантике. Если мой жесткий диск выйдет из строя и я восстановлю копию библиотеки iTunes из резервной копии, iTunes может работать некорректно из-за этого. Например, изменение содержимого одного файла не повлияет на другой. Удаление файла, на который указывает файл, означает, что вы больше не можете читать содержимое этого файла через символьную ссылку, которая снова отличается, если символическая ссылка заменяется копией этого файла. iTunes может аварийно завершить работу с поврежденной библиотекой или привести к дальнейшему повреждению библиотеки, что означает, что резервная копия не отвечает своей цели.

Гарантируется ли, что все действительные каталоги сжимаются в ZIP без ошибок и расширяются до идентичной копии исходного каталога без потери информации или семантических изменений? В частности, поддерживают ли ZIP-файлы все функции HFS +?

1. Symlinks
2. Жесткие ссылки (в том числе на каталоги, которые поддерживаются в HFS +)
3. Псевдонимы
4. Расширенные атрибуты
5. Ресурс вилки
6. списки управления доступом
7. Unix разрешения
8. Все допустимые имена путей в HFS +. Другими словами, поддерживает ли ZIP все символы, допустимые для использования в имени пути? Поддерживает ли ZIP самое длинное имя пути, которое вы можете создать в HFS +, или в формате ZIP существует более низкий предел длины пути?
9. Есть ли ограничение на размер файла 4 ГБ?

... и так далее.

Я обеспокоен возможностью скрытых изменений, которые могут привести к потере или повреждению данных без моего ведома, пока не станет слишком поздно.

Это вопрос о формате ZIP, а также о команде сжатия в Finder. Потому что даже если формат ZIP что-то поддерживает, а реализация Finder - нет, это не помогает.

Нет кредита для меня. Я буквально взял это от пользователя NSGod : https://superuser.com/a/222590

Мое собственное дополнение, немного очевидное:

• целевая файловая система должна поддерживать символические ссылки, жесткие ссылки и т. д., иначе она не будет работать
• Вы можете использовать zip введите в командной строке и сохраните эти типы файлов вручную zip --symlinks -r foo.zip foo/

Как вы создаете архив .zip в OS X? (С помощью инструмента командной строки, и если да, то какой, или с помощью утилиты архивирования и т. Д.)

На какой операционной системе работает целевой компьютер (где архив будет разархивирован) и какой метод вы используете для разархивирования файла?

Прежде всего, в OS X символические ссылки - это в основном простые текстовые файлы с некоторой дополнительной информацией «Mac», которая позволяет OS X знать, что он должен обрабатывать файл как символическую ссылку. Эта дополнительная информация для Mac представляет собой специальный тип файла, код создателя и информацию о флаге Finder, которая хранится не в самом файле, а в каталоге диска HFS +.

В OS X, когда вы создаете файл .zip, в потоке zip нет места для этой дополнительной информации Mac, поэтому, в некотором смысле, символическая ссылка сохраняется в файле zip как простой файл. Может ли кто-то на другом Mac разархивировать архив и правильно ли он представить исходную структуру, зависит от того, кто или что вы используете для его разархивирования.

Например, около месяца назад компания выпустила игру поверх Steam, программного обеспечения для распространения игр Valve. В комплект игрового приложения входила библиотека Cid от NVIDIA в форме фреймворка, в котором внутренне используются символические ссылки. Первоначально была проблема со Steam, неправильно восстанавливающим необходимую информацию Mac на Trine.app, как упомянуто в этой теме: http://forums.steampowered.com/forums/showthread.php?t=1556083

На изображении ниже показаны 2 разные копии Cg.framework, одну я установил отдельно от веб-сайта NVIDIA (верхнее изображение), а нижнее изображение показывает, что было получено с игрой:

Обратите внимание, что все элементы совпадают, но символические ссылки должны быть простыми файлами данных.

После более внимательного изучения записи FSCatalogInfo для обоих элементов мне стало ясно, в чем заключается проблема:

На верхнем изображении вы заметите, что начало структуры finderInfo имеет следующие значения:

0x736C6E6B = 'slnk'
0x72686170 = 'rhap'

Эти значения определены в /usr/include/hfs/hfs_format.h:

/*
 *  File type and creator for symbolic links
*/
enum {
    kSymLinkFileType  = 0x736C6E6B, /* 'slnk' */
    kSymLinkCreator   = 0x72686170  /* 'rhap' */
};

Значение 9-го байта 0x80 соответствует kIsAlias флаг finderInfo.finderFlags, Это значение определено в /System/Library/Frameworks/CoreServices.framework/.../CarbonCore.framework/.../Headers/Finder.h:

enum {
    kIsAlias                      = 0x8000 /* Files only */
};

Похоже, что функция распаковки, встроенная в OS X (Archive Utility), жестко запрограммирована для поиска возможных файлов в разархивированном архиве, которые представляют символические ссылки, и для установки информации соответствующим образом. я полагаю, что /usr/bin/ditto (когда используется для его способности архивировать файлы) также заботится об этом для вас. Я не уверен zip или же unzip делать.