Total7zip

[Mellomann]

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

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

часто в таких блоках файлы сортируются по расширению, чтобы сгруппировать похожие данные

А вот тут эпик фэйл. С одной из 15.хх автор 7zip подложил нам свинью в сортировку под видом "оптимизации" (читаем здесь ветку от Chelovek K.), он теперь умолчательно сортирует по имени вместо расширения. Естественно, страдает % сжатия и порядок обработки, но... Видать у автора свои соображения есть по этому поводу... Хорошо хоть параметром "qs" можно вернуть всё обратно.

Можно посмотреть, в принципе, исходники вроде открыты.

Надо знать

Было бы очень кстати, если кто-то знающий есть поблизости... Буду признателен, если найдётся и поможет.

[MVV]

Тотал всё равно читает как подряд в архиве идёт (или это плагин ему так отдаёт), так что проблемы порядка файлов из схожих архивов быть не должно.

Ну в WCX API есть функция ReadHeader[Ex] для получения следующего файла, так что тотал может читать в том порядке, в каком файлы лежат в архиве, но вполне возможно (не знаю точно), что при синхронизации он будет запрашивать файлы в том порядке, в котором они отображаются в окне. Кстати, по идее между вызовами функции ReadHeader контекст в архиваторе должен сохраняться: когда с помощью ReadHeader тотал доходит до нужного файла, он извлекает его с помощью ProcessFile; вопрос лишь, закрывает ли он архив потом или продолжает - по уму, должен продолжать.

С одной из 15.хх автор 7zip подложил нам свинью в сортировку под видом "оптимизации"

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

[Mellomann]

Если чтение мелких файлов с диска при сортировке по расширению идёт долго

То оно будет в любом случае долго.
У меня, вон, почти 10 часов одним потоком на HDD самосборный архив с HL2 пакуется, внутри около 400'000 (0,4 млн) мелких файлов и даже при "qs yx=9" вполне себе шустро находит их все и делает анализ содержимого и где-то через час жмёт себе в архив. Без "qs" - то же час, но жмётся в разы хуже. А на SSD было бы и без того смешнее...

[Mellomann]

Ещё обнаружил проблему при работе с плагином. Невозможно запустить одновременно несколько заданий. Т.е., пока первый архив не допакуется, тотал просто висит заблоченный и ждёт, пока процесс закончится, а после этого уже предлагает другой 7зиповый гуи. Непорядок.

[M-A-X]

Постоянно создает файл Total7zip.xml в той же папке, где и архивируемая папка/файл
TC 6.54a
Windows XP x86

[Avada]

M-A-X
Лично у меня файл Total7zip.xml лежит там, где и должен в портабельном TC — в папке плагина. О других корректных вариантах сохранения см. справку (readme_ru.rtf).
Версия TC 6.54a выпущена десять лет назад, давно пора обновлять, даже если очень не хочется. Заодно, скорее всего, и проблема отпадёт. А вообще такие размножения файла настройки упоминались в теме неоднократно (см., например, здесь), по форуму или в текущей теме вполне можно было поискать самостоятельно.
Кстати, используемую версию плагина тоже неплохо бы указывать.

[M-A-X]

Последняя версия
0.8.5.6
wincmd.ini хранится в папке с программой

[Avada]

M-A-X
Ясно. Обновляйте Total Commander. (Из официального дистрибутива, а не сборку, само собой.) Обсуждать работу этого плагина (как и многих других) на TC 6.x нет вообще никакого смысла.

[Skif_off]

Отсюда:

Ребят, почему Total Commander неправильно распаковывает (не может извлечь) драйвера NVIDIA GeForce?
Это 7-zip SFX - его и WinRar и 7-zip нормально распаковывает.

Потому что ТС почему-то распознаёт его как cab. Достаточно изменить расширение на 7z.

ИМХО, повод для баг-репорта Гислеру.

Добавлено:
Память не подвела, обсуждалось.

[MVV]

Не пойму, как-то странно плагин работает (то ли всегда так было, но не замечал, то ли в последнее время).

Распаковываю непрерывный архив по Alt+F9, нижняя шкала прогресса несколько раз заполняется, прежде чем все файлы распакуются, причём за каждое её заполнение счётчик обработанных файлов инкрементируется на константу (при дефолтном конфиге - на 20, если уменьшу extractToTempCount до 1, то на 1). Не может же быть такого, что порядок запрашиваемых файлов настолько не совпадает с порядком файлов в архиве, что надо делать кучу проходов? Причём такое поведение наблюдаю как со старым тоталом 8.52а, так и с новым 9.11б11. Версия 7-Zip: 9.20.

При распаковке через системный 7-Zip всё проходит гладко за один проход и соответственно за гораздо (в несколько раз) меньшее время.

Если на абстрактном архиве этого не видно, привожу конкретный архив: System.7z из Revision_1_1_0_0_SteamInstaller.exe. Но у меня такое с любым 7Z-архивом наблюдается.

[Mellomann]

Не может же быть такого, что порядок запрашиваемых файлов настолько не совпадает с порядком файлов в архиве, что надо делать кучу проходов?

Ещё как может.
Особенно, если архив правильный, сделан со всеми возможными фильтрами (типа bcj, delta и т.п.). А ещё не забываем про свежую свинью у 7zip с какой-то из 15.х версий (не вспомню с какой конкретно из них), дефолтно внутренний порядок файлов идёт не по расширениям, а тупо по имени... Хочешь красиво - указывай отдельно комстроковым параметром. И если этот самый архив распаковывать "по привычке"... Как говорят, "маємо шо маємо".
Сам же 7zip (не плагин) распаковывает подряд что видит, ибо сам себе очередь выстраивает.

[MVV]

Тотал тоже по идее при распаковке по Alt+F9 должен по порядку извлекать файлы. А архивы у меня самые обычные безо всяких извращений.

[Mellomann]

Наткнулся на весьма интересную вещицу:
https://mcmilk.de/projects/7-Zip-zstd/

7-Zip-zstd
7-Zip with support for Zstandard, which is a fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level compression ratio.

Качаем Codecs.7z и кладём нужной разрядности DLLку в папку Codecs возле 7z.exe (если её нет, папку надо создать).
Чтоб проверить правильность подключения, запускаем в комстроке "7z.exe i" и ищем среди кодеков строку " 1 ED 4F71101 ZSTD".
Если есть - радуемся, кодек ZSTD подключен, можно пользоваться.

Суть дела - поддержа архивов 7z с использованием сего алгоритма сжатия. Можно слоями с остальными алгоритмами типа BCJ, можно только его одного.
В гуёвой версии 7zip внизу в строку пишу "qs yx=9 0=zstd x22", получаю архивы почти такого же уровня сжатия, как и на LZMA2 (при прочих равных настройках, режим Ultra).
Мой конфиг: http://savepic.net/8396278.png
Конечно, переплюнуть его ему не удаётся, но иногда приближается к lzma2 по качеству сжатия довольно близко (разница всего несколько %).

Предлагаю присоединяться к тестированию связки
Total Commander x64 + Total7Zip.wcx64 + 7z.exe + Codecs\zstd-x64.dll
или её 32-битного варианта.

з.ы.
Там же автор предлагает форк 7зипа с уже вшитым своим форматом, но внутренний перфекционист во мне отвергает всякие вторжения в чистый 7z.exe. Так что за клона не скажу ничего, но доп. кодек к нормальному (оригинальному) 7зипу вполне себе работает.

[MVV]

Не понял, в чём смысл, если при сжатии в LZMA2 и так получается уровень сжатия как на LZMA2... Или всё-таки где-то опечатка? И вообще, смысл использовать заведомо сторонние и менее популярные форматы, если они не превосходят стандартные и популярные?

[Mellomann]

MVV
Ну... кто-то же использует до сих пор разные uha, arj, lha и т.п.. Вот ещё один к ним.
А если по сути, то вполне себе неплохой алгоритм, работает достаточно шустро.
Опечатки нет. Пока успел только на жпегах погонять его и на сохранёнках от игр.
На реальной инфе, может быть, у него и получится обойти непобедимого lzma2.
Интерес чисто академический, если оно есть - почему бы не попробовать.