В TC 11.00 заменена библиотека для работы с ZIP

Hobo · Сообщение **Hobo** » Пт май 05, 2023 17:27

New functions and fixes in Total Commander 11.00:
File operations:
- High speed packing and unpacking of ZIP and GZ files with modified libdeflate library

Ранее использовалась библиотека InfoZIP. Кстати, в "About" до сих пор -- INFO-ZIP.

Лично для меня это -- самое значимое изменение, потому что ежедневно пользуюсь обновлением, распаковкой, синхронизацией ZIP-архивов. А что, если после перехода на 11-ю версию, в один прекрасный день мои наработки превратятся в...? Как она будет работать с архивами от 10-й?

Решил проверить. Использовались версии 10.52 (далее -- 10) и 11.00b1 (11).

Запаковал обеими версиями каталог с файлами .html, .png, .jpg. Примерно 1,5 тыс. файлов. Причём в .html в качестве символа новой строки используется не пара CRLF, а просто LF. У 11-й архив оказался примерно на 0.1% меньше (про скорость пока не важно). Т.е. в результате получаются разные архивы.

Распаковал оба архива обеими версиями и сравнил по содержимому. Всё идентично оригиналу.

Команда unzip -Z <arc.zip> после размера файла выводит его тип (t - текст, b - двоичный), как здесь:

Код: Выделить всё

Archive:  tc1100x32_b1.exe
Zip file size: 5510920 bytes, number of entries: 7
-rw-a--     2.0 fat     1142 t- stor 23-May-03 11:00 FILE_ID.DIZ
-rw-a--     2.0 fat  5281931 b- stor 23-May-03 11:00 INSTALL.CAB
-rw-a--     2.0 fat     4677 t- stor 23-May-03 11:00 INSTALL.INF
-rw-a--     2.0 fat    56756 t- stor 23-May-03 11:00 INSTALL.LNG
-rw-a--     2.0 fat     4217 t- stor 23-May-03 11:00 LIESMICH.TXT
-rw-a--     2.0 fat     3407 t- stor 23-May-03 11:00 README.TXT
-rw-a--     2.0 fat       89 t- stor 23-May-03 11:00 TotalCommander.URL
7 files, 5352219 bytes uncompressed, 5352219 bytes compressed:  0.0%

Выяснилось, что для .html файлов библиотеки по-разному решают, какого типа файл, двоичный или текстовый. Иногда их мнения совпадают, иногда нет. Отсюда и разница в размере архива. Видимо, тут ещё дело в том, что .html файлы у меня в unix-формате.

И меня по-прежнему "терзают смутные сомнения", а что, если разница не только в этом, и в один прекрасный день...?

Avada · Сообщение **Avada** » Пт май 05, 2023 18:43

Hobo
Не поясните подробнее, что же такого не происходящего сейчас может произойти в один прекрасный день и что для предотвращения этого дня предлагается предпринять?
И вас, похоже, не озаботил (даже чисто теоретически) обратный вопрос — поддержка вновь созданных архивов, к примеру, старыми версиями TC...
(Как по мне, так все эти опасения примерно в одну цену и никакими фактами на данный момент не подтверждаются.)

Hobo · Сообщение **Hobo** » Сб май 06, 2023 13:25

Avada писал(а):Hobo
Не поясните подробнее, что же такого не происходящего сейчас может произойти в один прекрасный день и что для предотвращения этого дня предлагается предпринять?

Допустим, достал я из архива какой-нить старый ZIP, обновил в нём пару файлов, положил его обратно и забыл на некоторое время. А потом оказалось, что обновился он некорректно.

Тут, конечно, дело привычки. Я лет двадцать пользуюсь TC для работы с ZIP-ами. И всё это время был InfoZIP. И тут -- БАЦ! Ни с того, ни с сего -- другая библиотека. Вот и мандражнул децл и стал проверять. Да, с новой библиотекой даже на глаз, даже на HDD видна, хоть и небольшая, но разница в скорости. Но это как с методами сжатия по умолчанию и 9. Разница есть, но смысла особого от этого нет. А вот смысл в сохранности данных есть.

Оставаться на 10.* предотвратит. Но всё равно когда-то придётся обновляться.

И вас, похоже, не озаботил (даже чисто теоретически) обратный вопрос — поддержка вновь созданных архивов, к примеру, старыми версиями TC...

Я, наверно, неточно написал ранее. Было сделано два архива (10 и 11). Оба были распакованы обеими версиями TC и unzip-ом, который Info-ZIP. Результат распаковки сравнивался с оригиналом. Всё, казалось бы гут, но... Вот вам одна непоняточка:

В моём случае из ~400 .html libdeflate признал двоичными ~250, Info-ZIP не признал ни одного. Напомню, что все .html -- в unix-формате новой строки. Дело, естественно происходит в мирке, где CRLF.

У unzip-а есть опция -a:

convert text files. Ordinarily all files are extracted exactly as they are stored (as ‘‘binary’’ files). The −a option causes files identified by zip as text files (those with the ‘t’ label in zipinfo listings, rather than ‘b’) to be automatically extracted as such, converting line endings, end-of-file characters and the character set itself as necessary. (For example, Unix files use line feeds (LFs) for end-of-line (EOL) and have no end-of-file (EOF) marker; Macintoshes use carriage returns (CRs) for EOLs; and most PC operating systems use CR+LF for EOLs and control-Z for EOF.

Т.е., при распаковке файлы, помеченные в архиве как текстовые, распакуются с конвертацией, а остальные -- без.

Есть же в настройках FTP, какие файлы передавать как текстовые, а какие нет.

Вот.

Как на этот флаг смотрит(ел) TC -- неизвестно. Конечно, если архив не будет покидать мира CRLF или распаковщику будет плевать на флаг "t", то, скорее всего, ничего не произойдёт.

(Как по мне, так все эти опасения примерно в одну цену и никакими фактами на данный момент не подтверждаются.)

Я не говорил, что "всё пропало" и, конечно, посмотрел что это за libdeflate. Да, это достаточно проверенный проект, всё с ним хорошо.
"Но осадочек остался..."

Смена библиотеки не означает смену формата. Deflate — это как раз формат, используемый в ZIP-архивации, и название библиотеки libdeflate всячески намекает, что именно этот алгоритм она и реализует. То есть никаких проблем совместимости не ожидается. Формат ZIP — это сжатие без потерь. То есть какими бы ни были данные, как бы их ни определяла библиотека, они после распаковки всегда обязаны оставаться точной копией оригинала, до каждого бита. Если обнаружится хотя бы минимальное несовпадение — в том числе смена формата концов строк — это будет повод для незамедлительного репорта Гислеру. (Точной идентичности самого ZIP-архива, разумеется, никто не обещает, но в этом обычно нужды и не возникает.)

unzip -a — это некий расширенный режим, где распаковываемые файлы подвергаются дополнительной обработке. По умолчанию эта опция не применяется и, если честно, я ни разу не слышал, чтобы кто-то ей вообще пользовался. Задачей архивации, повторюсь, обычно является сохранение абсолютно точной копии. Но если есть необходимость обеспечить совместимость с прежним поведением режима автокоррекции, то необходимо зарепортить это на оф. форум.

Естественно, сам по себе переход на другую библиотеку может привести к ошибкам, но для того и существует этап бета-тестирования, на котором ошибки предполагается обнаруживать, работая с некритичными данными, и исправлять.

Hobo · Сообщение **Hobo** » Пн май 08, 2023 15:19

Судя по Диспетчеру задач Win10 32-bit, 11b1 не освобождает память после упаковки. Заметил на ~150 Mb, ~5000 файлов. После нескольких упаковок TC по потреблению памяти приблизился к Firefox. М.б., я что-то делаю не так.

У меня не получается воспроизвести. Распаковал сначала 5 ZIP-архивов суммарным объёмом в 8,5 гигов и 3000 файлов. Потом дополнительно распаковал 870 мелких архивов на 1-2 файла каждый, суммарно на 450 Мб. Существенного изменения в потреблении памяти не заметил ни в одном из показателей.

Сразу после запуска
После распаковки больших архивов
После распаковки маленьких архивов

Виден незначительный рост Working set и Private Bytes, но большая его часть происходила не при распаковке, а когда я по каталогам гулял в поисках архивов.

Hobo · Сообщение **Hobo** » Пн май 08, 2023 16:16

Ключевое слово: упаковка.

~30 тыс. файлов, ~800 Mb.

После первой упаковки: https://imgur.com/EipzHXs
После второй: https://imgur.com/NWVHa3r

На тестировании/распаковке всё гут.

Пардоньте, не вчитался…
С упаковкой подтверждаю. Не как Firefox, конечно, но да, стабильно растёт и не освобождается. В 64-битной, кстати, тоже, причём значительно активнее.

Добавлено спустя 6 минут:

Закинул.
https://www.ghisler.ch/board/viewtopic.php?t=78939

MVV · Сообщение **MVV** » Вс май 14, 2023 08:28

Добавлю небольшое уточнение насчет совместимости. Сам по себе стандарт deflate определяет, как в архиве записывается информация для распаковки (словарь переиспользуемых последовательностей, обращения к ним и т.п.), при этом каждый упаковщик имеет свой алгоритм наполнения словаря, который в том числе зависит от степени сжатия. Поэтому ничего критичного в том, что два разных упаковщика выдают разные сжатые потоки, нет.

А вот насчёт ZIP-контейнера у разных упаковщиков, насколько я знаю, были разные подходы к записи тех или иных метаданных (в частности, юникодных имён файлов)...