LINUX.ORG.RU

Как добавляются новые файлы в архив?

 ,


0

3

Что-то информации по архивам совсем немного. Видимо, я не умею гуглить.

Мне просто хочется узнать, при добавлении файла(просто перетащить мышкой файл) в архив, используя архиватор с GUI, что с ним происходит(например, zip архив). Архив распаковывается, к нему добавляется файл и обратно все это архивируется; или происходит, грубо говоря, просто добавление байтов файла сверху к архиву?



Последнее исправление: letni (всего исправлений: 4)

Ответ на: комментарий от yars068

Разве там будет указан принцип работы архиваторов?

Видимо, я совершил ошибку, т.к. задал слишком много вопросов.

Мне просто хочется узнать, при добавлении файла в архив, что с ним происходит(например, zip). Архив распаковывается, к нему добавляется файл и обратно в архив; или происходит, грубо говоря, просто добавление байтов файла сверху к архиву?

letni
() автор топика
Ответ на: комментарий от letni

Обычно просто добавляетя в конец. Так покрайней мере с tar.gz

tar: на самом деле Tape-ARchiver, что многое уже значит. ;) Дописывает просто в конец (ленты). Если такой файл уже был, то из всех файлов с одинаковым именем в архиве при распаковке выигрывает последний.

gzip: а с ним прикол в том, что он потоковый. Т.е. можно просто сделать cat file1.gz file2.gz > file.gz. Т.ч. для того, что бы добавить файл к tar.gz его не надо распаковываеть, а просто дописать в конец.

ref1: http://www.gnu.org/software/tar/manual/html_node/appending-files.html

ref2: http://stackoverflow.com/questions/8005114/fast-concatenation-of-multiple-gzi...

По поводу других затрудняюсь что-либо сказать. tar.gz хватит всем!

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 2)

Под SOLID опцией у архиваторов обычно подразумевают что все файлы подлежащие упаковки рассматриваются как один поток байт, который и пакуется. При этом запоминается где в исходном сквозном потоке байт лежал какой файл. При этом умный архиватор файлы одинакового типа(подобного содержания) расположет рядом в потоке, для улучшения качества сжатых данных. Не SOLID упаковка - каждый файл(поток байт) пакуется отдельно. Это оправдывает себя для тучи файлов одинакового типа/подобного содержимого(например тексты, текстовые форматы и т.п.) для словарных алгоритмов сжатия. Распаковка такого архива соответственная: если нужны все файлы - это будет быстро, если нужен набор файлов, то архиватору нужно посмотреть где раньше лежали файлы, и распаковать соответствующий участок. А вот тут уже включаются особенности алгоритма сжатия: алгоритм может быть блочным, а может быть потоковым. Под блочным подразумевается: сжатый поток данных состоит из блоков которые могут быть самостоятельно распакованы, т.е. не требуют знания что было в предыдущем блоке. (т.е. данные склеены вместе но обрабатываются конечными порциями). Вот если алгоритм блочный - извлечение одного файла упрощается до поиска блоков ответственных за его данные, т.е. (много)лишнего не распакуют. При поточном - не повезло, всё делаем сначала(распакованные данные которые не нужны просто нигде не сохраняют, только состояние декодера).
Это касалось распаковки. Теперь добавлении. С не SOLID-понятно. С SOLID - возможны вариации на тему:
1. Алгоритм упаковки выплюнул запакованый поток байт в файл и завершился(большинство алгоритмов). Т.е. потоковый алгоритм.. тут делать нечего, нужно всё что было развернуть и потом опять завернуть и(т.е. возобновить состояние кодера на момент истощения старых данных) продолжать заворачивать новые данные. Долго. И возможно требует место дополнительное для старых распакованных, данных, хотя это не обязательно(распаковщик выплевывает сразу в упаковщик, которому, если алгоритм подходящий, нет необходимости писать новые сжатые данные, ибо они бит-в-бит совпадают с существующими, он только сохраняет своё состояние).
2. Алгоритм выплюнул поток байт в архив И положил же туда своё состояние. Это значит что чтобы добавить файл достаточно поднять состояние и взяться за дело. Фактически алгоритмы сжатия которые выплевывают блочный поток просто сбрасывают своё состояние в исходное с каждым блоком. Добавить в таком случае файл просто: поднял состояние, сделал дело, положил состояние.

Это теория. Практика:
Популярные форматы потоков сжатых данных(deflate, lzma) - НЕ блочные. На самом деле гибридные. Тот же deflate это LZ77(потоковый, словарный, для сжатия очередных данных смотрит в то что уже сжимал раньше), выхлоп кормится в алгоритм Хаффмана, которые кушает блок данных за раз, сжимает, выплевывает, и сбрасывается и так пока есть вход. LZMA - тот же принцип: словарный потоковый сначала, блочный потом, т.е. тоже потоковый по факту.
Я не особо в курсе менее популярных форматов сжатия, но вероятнее всего они тоже полностью потоковые, либо очередной клон deflate.
Т.е. на практике в популярных форматах: что-то добавить в solid значит распаковать и запаковать снова. .

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

Под SOLID опцией у архиваторов обычно подразумевают что все файлы подлежащие упаковки рассматриваются как один поток байт
Не SOLID упаковка - каждый файл(поток байт) пакуется отдельно

Я что-то не пойму, в чем различие между ними по факту? Ведь система распознает SOLID и не SOLID архивы как один файл. Или, получается, не SOLID архив представляет из себя какой-то контейнер, в котором лежит много разных заархивированных файлов(грубо говоря, мини-архивов), а SOLID представляет из себя 1 заархивированный файл, внутри которого много других, но в виде сплошного потока?

letni
() автор топика
Ответ на: комментарий от letni

Абсолютно верно. ZIP/RAR/7Z/ARJ/...-формат это контейнер, который может хранить много сжатых файлов. В режиме SOLID файлы сжимаются 1 потоком, не в режиме - каждый файл отдельно. Заметьте разницу между контейнером(форматом) и алгоритмом сжатия. ZIP, GZIP, BZIP2 - контейнеры. DEFLATE, LZMA, LZMA2 - алгоритмы сжатия. GIF(да, тот который картинка с анимацией) - контейнер, LZW - алгоритм сжатия который применен в GIF. BMP - контейнер, RLE - алгоритм сжатия который иногда используется внутри BMP. MKV, AVI, WAV, - контейнеры которые хранят медиа данные, a-law, u-law, mpeg4, mp3, acc, srt/ass(субтитры) - алгоритмы которые определяют как конкретные данные записываются в байты.(вернемся к сжатию без потерь). Учтите, что контейнер сам себе хозяин и сам решает каким образом сжатые данные файлов хранить внутри. Хочет: 111122223333, хочет - 123123123. Архиваторы поступают первым спомобом, ибо их юзекейс - достать файл целиком, положить на ФС, достать след. Контейнеры - вторым способом - юзекейс - достать фрагмент видео, фрагмент аудио, фрагмент субтитров, и бегом отправить на рендер, ибо нужно в реальном времени обрабатывать данные из разных потоков.
ZIP контейнер, как правило используется алгоритм сжатия deflate для данных, этот контейер может хранить несколько файлов(логически независимых, т.е адресуемых). GZIP - тоже контейнер, тоже использует deflate но может хранить только 1 файл.BZIP2 - аналогично. Более того, многофайловые контейнеры могут каждый файл сжимать(или не сжимать вообще) независимо друг от друга. Они также могут сжатые данные дополнительно обработать, например зашифровать. 7z контейнер(точнее архиватор) на самом деле выполняет(если его попросить) анализ данных которые ему кормят, и даже принимает решение «стоит ли» и «чем». Ну грубо говоря, jpg, png в архиве не будут сжаты. .exe из оффтопика будут обработаны дополнительно перед сжатием.
Т.е ответом на начальный вопрос будет: а какой архив(контейнер)?
zip хитрый контейнер. И него главный «заголовок» и директория(структура в файле хранящая список файлов в архива) находится в хвосте(«заголовок» == «хвостовик» ;) ), и смещения соответственно не от начала файла, а от конца. Архиватор читает хвост и директория в память, добавляет описатель нового файла, сжимает новый, дописывает в конец файла(поверх где раньше лежала директория и «хвостовик»), и потом дописывает директорию и хвост. Сделано это очевидно для того чтобы можно было быстро добавлять новые файлы и метаданные не мутузя сжатые данные(если бы были в голове, то нужно было бы всё перечитать, и перезаписать). Также это очень на руку приему объедения двух файлов в один(sfx исполняемый любого формата + сам архив в хвосте файла, ОС ищет заголовки в начале и игнорит хвост ибо в заголовке написано сколько исполняемый файл занимает, а архиватор ищет в конце и игнорит голову, ибо тоже знает сколько данных его. Таким образом обоим нету необходимости знать лишнее).
Я к сожаление не в курсе каким образом разложен внутри solid zip, но это и не важно - используемое сжатие deflate не оставляет выбора кроме как разжать и сжать обратно.

FeyFre ★★★★
()
Ответ на: комментарий от FeyFre

Спасибо большое, теперь архив не является для меня таинственной штукой, в который хранятся сжатые файлы :)

Кстати, можете какую-нибудь утилиту посоветовать для работы с архивами? Возможно даже с низкоуровневыми параметрами, так как теперь, наверное, осилю. Я щас пользуюсь p7zip, но он корявенький.

letni
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.