Страница 56 из 68

Добавлено: Вт янв 13, 2015 06:14
c930
Skif_off писал(а):Ни разу не сталкивался с форматом ARJ...
Я только во времена DOSа пользовался ARJ архиватором. А последнее время чё-то вообще мало что архивирую, как практика показывает.

Добавлено: Вт янв 13, 2015 09:50
MVV
Я после 2000 паковал исключительно в CAB, а когда появился 7Z, стал и в него, особенно большие объёмы. И не понимаю, какой смысл сейчас использовать такие древние форматы как ARJ.

Добавлено: Вс янв 18, 2015 13:40
_92

Добавлено: Вс янв 18, 2015 15:05
Skif_off
_92
А 7zCon.sfx?

Добавлено: Вс янв 18, 2015 15:12
_92
Skif_off писал(а):А 7zCon.sfx?
тут его нет
http://wincmd.ru/plugring/Total7zip.html

Добавлено: Вс янв 18, 2015 17:21
Skif_off

Добавлено: Вс янв 18, 2015 21:24
_92
Skif_off писал(а):Тут есть
http://wincmd.ru/plugring/7zip_plugin.html
добавил

Добавлено: Пн янв 19, 2015 14:27
Skif_off
_92
Честно говоря, не уверен, что он нужен: не получилось нагуглить инфу о SFX-модулях и что происходит при изменении SFX-архива. .Сам создаю SFX с модифицированным модулем.

Добавлено: Вт ноя 24, 2015 04:51
Skif_off
7.dll 15.12 x86/x64, скомпилированные с поддержкой извлечения скрипта NSIS.

Добавлено: Сб янв 09, 2016 02:25
Mellomann
Total7zip писал(а):вот описание проблемы подробнее из readme_ru.rtf:
extractToTempCount - параметр управляет тем, сколько файлов извлекать из solid архива, если Total Commander просит извлечь файл в папку Temp. Увеличение количества извлекаемых за одну операцию файлов ускоряет поиск текста в solid архивах в несколько раз. С другой стороны - если вам действительно нужно извлечь только один файл в папку Temp, вместе с ним будут извлечены лишние файлы. Total Commander использует распаковку в папку Temp для просмотра или редактирования файла из архива, для поиска текста в архивах, для перепаковки из одного архива в другой и, возможно, еще в каких-то случаях. Мне неизвестно как отличить "распаковку для редактирования" от "распаковки для поиска". В API Total Commander об этом ничего не говорится. Если поставить значение 1, то лишние файлы извлекаться не будут, но поиск текста в solid архивах будет неимоверно долгим.
Значение по умолчанию 20. Ищите золотую середину.
1. Интересно, эта проблема до сих пор не решена?
2. А зачем вообще доставать из архива кучу заведомо ненужных данных?

Добавлено: Сб янв 09, 2016 13:01
MVV
1. Интересно, эта проблема до сих пор не решена?
Какая именно проблема? В непрерывных архивах файлы соединяются в большой виртуальный файл (поток), который и сжимается, и чтобы достать что-то из его середины, нужно прочитать весь этот большой файл с самого начала, поэтому для извлечения отдельного файла нужно тем больше времени, чем дальше файл оказался в потоке. Это плата за улучшенную степень сжатия. Если хочется читать произвольные файлы быстрее, можно ограничить размер непрерывного блока, найти компромисс между степенью сжатия и скоростью произвольного доступа.
2. А зачем вообще доставать из архива кучу заведомо ненужных данных?
Параметр позволяет извлечь в кэш после запрошенного файла ещё несколько файлов, чтобы ускорить потенциально возможные запросы к ним (например, при полнотекстовом поиске, когда файлы запрашиваются по порядку).

Добавлено: Сб янв 09, 2016 13:07
Mellomann
1. Проблема в том, что из архива в любом случае будет писаться (например, здесь 20) некое количество заведомо ненужных данных. Хотелось бы этого избежать не в ущерб скорости работы.

2. По солид-архивам принцип работы понятен и вполне предсказуем. Я о другом. Тот же RAR, например, даже в новых версиях с огромными словарями не вытаскивает в темп кучу лишнего, и при этом по 100 раз не перечитывает уже пройденное.

Добавлено: Сб янв 09, 2016 13:10
MVV
Тот же RAR, например, даже в новых версиях с огромными словарями не вытаскивает в темп кучу лишнего, и при этом по 100 раз не перечитывает уже пройденное.
Это при каких конкретно операциях? Здесь необходимо учитывать, что плагин обрабатывает запросы от тотала и должен вписываться в интерфейс, в то время как в RAR распаковщик изначально затачивается под конкретный набор команд, которые могут прийти от оболочки, и если это текстовый поиск, то там скорее всего всё выполняется в одной процедуре.
Вообще, я плохо знаю интерфейс взаимодействия с библиотекой 7-Zip, поэтому сложно сказать, можно ли вместо этого просто приостановить дальнейшую обработку архива (оставив в памяти промежуточные данные) и продолжить её при запросе следующего файла, но потенциально такой способ был бы лучшим (если не обращать внимания на сотню-другую мегабайт временно занимаемой памяти).

Добавлено: Сб янв 09, 2016 13:14
Mellomann
MVV
Например, синхронизация каталогов, перепаковка нескольких файлов из одного 7z напрямую в другой 7z...
И ещё немного инфы к размышлению: тот же 7zip.wcx в этом плане работает нормально - ни лишних избыточных данных в темпе, ни просадки в работе не замечено.
Возможно, есть смысл сравнить и по его подобию поэкспериментировать...
можно ли вместо этого просто приостановить дальнейшую обработку архива (оставив в памяти промежуточные данные) и продолжить её при запросе следующего файла
Правильное решение. Память-то всё равно в конце будет освобождена...

Добавлено: Сб янв 09, 2016 16:59
MVV
синхронизация каталогов
Если без сравнения по содержимому, то распаковка не требуется. Если со сравнением - тут эта опция может помочь. И то в случае, если порядок файлов для синхронизации совпадает с порядком файлов в непрерывном блоке (часто в таких блоках файлы сортируются по расширению, чтобы сгруппировать похожие данные - но тотал никак не может узнать этот порядок), иначе всё равно потребуется много новых заходов. При сравнении двух архивов с разным порядком файлов в непрерывных блоках в любом случае потребуется множество заходов, и это верно и для RAR.
перепаковка нескольких файлов из одного 7z напрямую в другой 7z
Опять же, если файлы из непрерывного архива, то для извлечения каждого из них может потребоваться новый проход. Если новый архив непрерывный, то они будут помещены в новый непрерывный блок.
тот же 7zip.wcx в этом плане работает нормально
Не знаю, как он работает, возможно, он сохраняет контекст. Можно посмотреть, в принципе, исходники вроде открыты.
Правильное решение. Память-то всё равно в конце будет освобождена...
Надо знать интерфейс библиотеки 7Z.dll, чтобы сказать, можно ли так сделать в случае плагина типа Total7zip.