Я только во времена DOSа пользовался ARJ архиватором. А последнее время чё-то вообще мало что архивирую, как практика показывает.Skif_off писал(а):Ни разу не сталкивался с форматом ARJ...
Total7zip
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
7.dll 15.12 x86/x64, скомпилированные с поддержкой извлечения скрипта NSIS.
1. Интересно, эта проблема до сих пор не решена?Total7zip писал(а):вот описание проблемы подробнее из readme_ru.rtf:
extractToTempCount - параметр управляет тем, сколько файлов извлекать из solid архива, если Total Commander просит извлечь файл в папку Temp. Увеличение количества извлекаемых за одну операцию файлов ускоряет поиск текста в solid архивах в несколько раз. С другой стороны - если вам действительно нужно извлечь только один файл в папку Temp, вместе с ним будут извлечены лишние файлы. Total Commander использует распаковку в папку Temp для просмотра или редактирования файла из архива, для поиска текста в архивах, для перепаковки из одного архива в другой и, возможно, еще в каких-то случаях. Мне неизвестно как отличить "распаковку для редактирования" от "распаковки для поиска". В API Total Commander об этом ничего не говорится. Если поставить значение 1, то лишние файлы извлекаться не будут, но поиск текста в solid архивах будет неимоверно долгим.
Значение по умолчанию 20. Ищите золотую середину.
2. А зачем вообще доставать из архива кучу заведомо ненужных данных?
Какая именно проблема? В непрерывных архивах файлы соединяются в большой виртуальный файл (поток), который и сжимается, и чтобы достать что-то из его середины, нужно прочитать весь этот большой файл с самого начала, поэтому для извлечения отдельного файла нужно тем больше времени, чем дальше файл оказался в потоке. Это плата за улучшенную степень сжатия. Если хочется читать произвольные файлы быстрее, можно ограничить размер непрерывного блока, найти компромисс между степенью сжатия и скоростью произвольного доступа.1. Интересно, эта проблема до сих пор не решена?
Параметр позволяет извлечь в кэш после запрошенного файла ещё несколько файлов, чтобы ускорить потенциально возможные запросы к ним (например, при полнотекстовом поиске, когда файлы запрашиваются по порядку).2. А зачем вообще доставать из архива кучу заведомо ненужных данных?
Последний раз редактировалось MVV Сб янв 09, 2016 13:10, всего редактировалось 2 раза.
1. Проблема в том, что из архива в любом случае будет писаться (например, здесь 20) некое количество заведомо ненужных данных. Хотелось бы этого избежать не в ущерб скорости работы.
2. По солид-архивам принцип работы понятен и вполне предсказуем. Я о другом. Тот же RAR, например, даже в новых версиях с огромными словарями не вытаскивает в темп кучу лишнего, и при этом по 100 раз не перечитывает уже пройденное.
2. По солид-архивам принцип работы понятен и вполне предсказуем. Я о другом. Тот же RAR, например, даже в новых версиях с огромными словарями не вытаскивает в темп кучу лишнего, и при этом по 100 раз не перечитывает уже пройденное.
Это при каких конкретно операциях? Здесь необходимо учитывать, что плагин обрабатывает запросы от тотала и должен вписываться в интерфейс, в то время как в RAR распаковщик изначально затачивается под конкретный набор команд, которые могут прийти от оболочки, и если это текстовый поиск, то там скорее всего всё выполняется в одной процедуре.Тот же RAR, например, даже в новых версиях с огромными словарями не вытаскивает в темп кучу лишнего, и при этом по 100 раз не перечитывает уже пройденное.
Вообще, я плохо знаю интерфейс взаимодействия с библиотекой 7-Zip, поэтому сложно сказать, можно ли вместо этого просто приостановить дальнейшую обработку архива (оставив в памяти промежуточные данные) и продолжить её при запросе следующего файла, но потенциально такой способ был бы лучшим (если не обращать внимания на сотню-другую мегабайт временно занимаемой памяти).
MVV
Например, синхронизация каталогов, перепаковка нескольких файлов из одного 7z напрямую в другой 7z...
И ещё немного инфы к размышлению: тот же 7zip.wcx в этом плане работает нормально - ни лишних избыточных данных в темпе, ни просадки в работе не замечено.
Возможно, есть смысл сравнить и по его подобию поэкспериментировать...
Например, синхронизация каталогов, перепаковка нескольких файлов из одного 7z напрямую в другой 7z...
И ещё немного инфы к размышлению: тот же 7zip.wcx в этом плане работает нормально - ни лишних избыточных данных в темпе, ни просадки в работе не замечено.
Возможно, есть смысл сравнить и по его подобию поэкспериментировать...
Правильное решение. Память-то всё равно в конце будет освобождена...можно ли вместо этого просто приостановить дальнейшую обработку архива (оставив в памяти промежуточные данные) и продолжить её при запросе следующего файла
Если без сравнения по содержимому, то распаковка не требуется. Если со сравнением - тут эта опция может помочь. И то в случае, если порядок файлов для синхронизации совпадает с порядком файлов в непрерывном блоке (часто в таких блоках файлы сортируются по расширению, чтобы сгруппировать похожие данные - но тотал никак не может узнать этот порядок), иначе всё равно потребуется много новых заходов. При сравнении двух архивов с разным порядком файлов в непрерывных блоках в любом случае потребуется множество заходов, и это верно и для RAR.синхронизация каталогов
Опять же, если файлы из непрерывного архива, то для извлечения каждого из них может потребоваться новый проход. Если новый архив непрерывный, то они будут помещены в новый непрерывный блок.перепаковка нескольких файлов из одного 7z напрямую в другой 7z
Не знаю, как он работает, возможно, он сохраняет контекст. Можно посмотреть, в принципе, исходники вроде открыты.тот же 7zip.wcx в этом плане работает нормально
Надо знать интерфейс библиотеки 7Z.dll, чтобы сказать, можно ли так сделать в случае плагина типа Total7zip.Правильное решение. Память-то всё равно в конце будет освобождена...