Ru-Board.club
← Вернуться в раздел «Программы»

» WinRAR (часть 2)

Автор: bar22890
Дата сообщения: 16.01.2014 17:25
А как это сделать, мне нужен образ, но достать не получается. Подскажите как это делается.
Автор: SAT31
Дата сообщения: 16.01.2014 17:36
bar22890
Необходимо, чтобы все части (тома) были в одной папке. При распаковке архиватор сам распакует все части по очереди.
Автор: lvqcl
Дата сообщения: 17.01.2014 18:15
Почему файл называется чтототам.part1(1).rar?
Автор: Victor_VG
Дата сообщения: 17.01.2014 19:02
lvqcl

Посмотрите в документации схему именования томов. Это первый том многотомного архива.
Автор: EugeneRoshal
Дата сообщения: 17.01.2014 19:38
lvqcl

Цитата:
Почему файл называется чтототам.part1(1).rar?

Видимо, какая-то программа переименовала. Например, скачивали один файл два раза, первая копия сохранилась как part1.rar, а вторая как part1(1).rar
Автор: Victor_VG
Дата сообщения: 17.01.2014 20:05
EugeneRoshal

Кстати, точно! Браузеры на ядре Хрома автоматом так сохраняют если файл существует. Я и забыл про эту их особенность. У самого ведь стоит Дракон и он если файл существует молча добавляет к имени (?) и сохраняет вторую копию - это его стандартное поведение из коробки.
Автор: maik2
Дата сообщения: 21.01.2014 10:48
Подскажите? Можно извлечь по нормальному кусок фильма из part1.rar? Второй части нет (допустим) просто глянуть как и что... Или посмотреть плеером каким-нибудь.
Автор: savant_a
Дата сообщения: 21.01.2014 11:23
maik2
ПКМ->Извлечь файлы...->Оставить на диске поврежденные файлы (скрин).
Автор: Povor
Дата сообщения: 21.01.2014 12:49
Нужно архивировать какое-то количество файлов и папок, с разделением архивов по 3,9Гб. Выделяю файлы и папки, задаю:
1 Разделить на тома размером 3,9Гб
2 Каждый файл в отдельный архив
Получаю папки архивированные в заданных параметрах - 3,9Гб, но файлы упаковываются без разделения - каждый файл, в отдельный архив
Вопрос - как упаковать выделенные файлы и папки с разделением нужным размером.
Спасибо.
Автор: V0lt
Дата сообщения: 21.01.2014 20:52
Povor

Цитата:
Получаю папки архивированные в заданных параметрах-3,9Гб, но файлы упаковываются, без разделения - каждый файл, в отдельный архив

У тебя WinRAR работает строго по заданным тобою опциям.
Автор: KeeperArchive
Дата сообщения: 21.01.2014 23:06
EugeneRoshal

Здравствуйте. Есть два вопроса.

1. При обновлении архива учитывается только дата/время создания/изменения архивируемых файлов. Однако, бывают ситуации, когда дата/время остаются прежними, но меняется содержимое файла. Реально ли добавить возможность выбора - либо дата, либо CRC?
Понимаю, что при сравнении контрольных сумм файлов в архиве и файлов на диске фактически нужно перечитать все файлы на диске. Но такая возможность будет очень не лишней, IMHO

2. Используя наилучшее сжатие режима RAR5 заметил увеличение времени архивации. Конечно, чем лучше/выше сжатие, тем больше времени оно занимает. Это естественно, а потому не безобразно.
Предлагаю Вам мысленно вернуться на много лет назад и представить размер архивов того времени.
Сейчас же, приблизительно представив время, необходимое на создание полного архива HDD размером 2...3 Тб приходишь в тихий ужас...
вопрос: можно ли надеяться/ожидать реализацию функции упаковки, используя ресурсы компьютеров, подключенных по локальной сети ?
Пример: многие видеоредакторы/кодировщики позволяют кодировать видео, распределяя задачу между многими компьютерами (клиен-серверная реализация ?).
На моей памяти ни один архиватор не поддерживает такую возможность... Вы будете первый...

Спасибо
Автор: Victor_VG
Дата сообщения: 21.01.2014 23:51
KeeperArchive

По пункту 2 вам отвечу я - теоретически можно сжимать архив на скорости ОЗУ, но если суммарный объём данных и необходимых для сжатия буферов станет больше максимально доступного задаче размера ОЗУ то определяющей станет скорость работы подсистемы внешней памяти (в данном случае дисковой) и даже кластер суперЭВМ с самими призводительными ЦП не ускорит задачу из-за чтения данных с медленной внешней памяти.

Я ещё в 94-м году отвечал на подобный вопрос одного из банков - они хотели бэкапить всю дисковую подсистему сервера DEC AlphaSERVER 10000 AXP (13 Тб), но времени это занимало... Их идея была проста - кластер из нескольких серверов и архивация в ОЗУ. Но у данного сервера предельный объём ОЗУ 14 Гб, и даже 12 ЦП DEC Alpha AXP 21064A @ 275 MHz (тогда это были самые мощные из промышленно выпускавшихся ЦП) в каждой процессорной стойке не смогли бы ускорить решение задачи. Это при условии что для соединения узлов кластера используются каналы с пропускной способностью большей чем суммарный пиковый трафик порождаемый в кластере.
Автор: persicum
Дата сообщения: 22.01.2014 05:34
KeeperArchive
1) если crc изменилось, а время модификации нет, то скорее всего файл повредился или заразился. Сомнительная фича. Может, криптоконтейнеры?

2) для архивирования целых винтов основным источником экономии места будет не сжатие файлов, а тупые повторы - дедупликация. Для дедупликации есть архиватор zpaq - я сейчас с ним балуюсь. Если архив уже создан, то добавление к нему измененной версии будет происходить вообще мгновенно, так как пропишется только diff, да и то в конец припишется и все.

Ща взял случайную папку 3G и обработал по умолчанию rar и zpaq. -))

rar a -r -s test - получилось 1.9G
zpaq a test * - получилось 0.9G - причем шустренько -)))

Дело тут конечно не в лучшем сжатии, а в дедупликации. Значит, были повторы внутри файлов.
Автор: Povor
Дата сообщения: 22.01.2014 07:38
Povor 21-01-2014
Если переложить файлы в папку, то получим на выходе нужную структуру архивов - файлы попадут в одни архивы, а вспомогательные данные в другие. http://iceimg.com/EElrltEU/r.png
Странно, что такая очевидность сразу не пришла мне в голову
Автор: EugeneRoshal
Дата сообщения: 22.01.2014 09:51
KeeperArchive

Цитата:
Реально ли добавить возможность выбора - либо дата, либо CRC?

Реально. Не исключаю в будущем, хотя задача довольно редкая.

Цитата:
можно ли надеяться/ожидать реализацию функции упаковки, используя ресурсы компьютеров, подключенных по локальной сети

Вот это очень вряд ли. Слишком трудоемко, причем в итоге можем упереться в пропускную способность сети.

Цитата:
Сейчас же, приблизительно представив время, необходимое на создание полного архива HDD размером 2...3 Тб приходишь в тихий ужас...

У меня, как пользователя, та же задача. Решение: выделить объемные файлы, которые никогда не меняются, например, iso из msdn, сбэкапить их один раз и исключить из регулярного бэкапа. Исключить мусорные временные файлы типа precompiled headers, если такие есть. Все плохо жмущееся типа архивов, jpg, avi, прописать в "Files to store without compression" или в ключе -ms. Использовать не наилучшее сжатие, а самое быстрое. Наилучшее нужно для обмена файлами, для распространения файлов, но для большого регулярного бэкапа важнее скорость.

persicum

Цитата:
для архивирования целых винтов основным источником экономии места будет не сжатие файлов, а тупые повторы - дедупликация

Конечно, у разных пользователей и данные разные, но по моим наблюдениям все большую долю в объеме данных среднестатистического пользователя получают фото и видео. Я имею в виду уникальные данные, произведенные самим пользователем. Именно они, как правило, регулярно бэкапятся, так как остальное можно скачать заново. И в структуре таких данных сейчас заметный перевес в сторону фоток и домашнего видео просто в силу их большого размера. А для них дедупликация мало что даст, тут просто надо включать "store" или "fastest" сжатие.

Цитата:
rar a -r -s test - получилось 1.9G

Можно включить rar5 и словарь хотя бы в 32мб.
Автор: oshizelly
Дата сообщения: 22.01.2014 13:39
KeeperArchive 23:06 21-01-2014
Цитата:
При обновлении архива учитывается только дата/время создания/изменения архивируемых файлов. Однако, бывают ситуации, когда дата/время остаются прежними, но меняется содержимое файла. Реально ли добавить возможность выбора - либо дата, либо CRC?

+1

persicum 05:34 22-01-2014
Цитата:
1) если crc изменилось, а время модификации нет, то скорее всего файл повредился или заразился. Сомнительная фича

EugeneRoshal 09:51 22-01-2014
Цитата:
Реально. Не исключаю в будущем, хотя задача довольно редкая.

Не факт, что повредился, и задача не так чтобы уж сильно редкая.
Некоторые текстовые редакторы (например, знаменитый Akelpad , UltraEdit и другие) и графические программы (например, знаменитый IfranView) имеют штатную опцию: "сохранять оригинальное время модификации" (при сохранении на диск изменённого файла). А в некоторых случаях приходится даже руками восстанавливать оригинальное время модификации после изменения. Когда и почему это необходимо, объяснять не буду, ибо офф-топ. Но, поверьте, это реально нужно, и этом многие пользуются. Так что задача, поставленная KeeperArchive, отнюдь не экзотическая.

Другое дело, что в таких случаях в результате редактирования обычно изменяется размер файла. Так что, можно бы ограничиться проверкой совпадения размера. Но ведь может совпасть и так, что в результате редактирования файла размер случайно останется тот же самый.
Автор: persicum
Дата сообщения: 22.01.2014 14:12

Цитата:
Цитата:
>rar a -r -s test - получилось 1.9G

Можно включить rar5 и словарь хотя бы в 32мб.


Со словарем получше получилось, 1.5 G с ключами:
rar a -r -ma5 -s -md256m -m4 test

Но против дедупликации не попрешь - это считай бесконечный словарь -)))

Теперь в дополнение к WinRAR приходиться zpaq осваивать -((.


Цитата:
(например, знаменитый IfranView) имеют штатную опцию: "сохранять оригинальное время модификации" (при сохранении на диск изменённого файла). А в некоторых случаях приходится даже руками восстанавливать оригинальное время модификации после изменения.


У меня только знаменитый hiew файлы изменяет, а время сохраняет -)).

Кста, zpaq хотя и не пересохраняет версии файлов если время не изменилось, но если изменилось CRC файла он про это говорит (если дать нужную команду).
Автор: Victor_VG
Дата сообщения: 22.01.2014 18:18
persicum

Ну, есть вообще элементарное решение - хардлинки на дублирующиеся файлы. Консоли не боитесь? Если не боитесь, то воспользуйтесь утилитой hdlink: HardLink duplicate files 32x64 v1.15 написанной Андреем Гречкиным. Она хоть и проста в работе, но в вашем случае сэкономит не мало места на дисках ибо хардлинк это запись файла в нескольких каталогах одновременно с увеличением его счётчика использования, но при этом дублирования его данных не происходит и его суммарный размер на диске Lsum определяется довольно простой формулой:

Lsum = {(K+1)*Lcat+Ldata} (1)

где:

Lsum - суммарное место занимаемое файлом на томе;
K - число связей файла;
Lcat - размер элемента записи каталога (определяется файловой системой, обычно несколько Кбайт);
Ldata - размер файла;

а у вас получается:

Lsum={N*(Ldata+Lcat)} (2)

где:

N - число копий файла
Lsum - суммарное место занимаемое файлом на томе;
Lcat - размер элемента записи каталога (определяется файловой системой, обычно несколько Кбайт);
Ldata - размер файла;

и естественно что {N*(Ldata+Lcat)} > {(K+1)*Lcat+Ldata}

думаю что из приведённых соотношений всё понятно.
Автор: Ajaja
Дата сообщения: 22.01.2014 18:48
Victor_VG

Цитата:
Ну, есть вообще элементарное решение - хардлинки на дублирующиеся файлы. Консоли не боитесь? Если не боитесь, то воспользуйтесь утилитой hdlink: HardLink duplicate files 32x64 v1.15 написанной Андреем Гречкиным.

Давно пользуюсь для этого утилитой fdf от автора imdisk:
http://www.ltr-data.se/opencode.html/
рекомендую
Автор: Userrr
Дата сообщения: 22.01.2014 19:17
что за хитрый архив?
распаковывается в папку с текущей датой, хотя на самом деле 20.01.2014

Добавлено:
как можно его распаковать с правильной датой?
Автор: Victor_VG
Дата сообщения: 22.01.2014 19:19
Ajaja

Таких утилит есть множество, к примеру dupemerge и ln от Gerhild Schinagl и Hermann Schinagl, просто не все ими пользуются и чаще всего просто по незнанию об их существовании...
    
Автор: persicum
Дата сообщения: 22.01.2014 19:19
Victor_VG
Речь идет о данных, продублированных скрытым образом -)). Например, есть оригинальный видеофайл и видеофайл, куда вы вставили несколько переходов, остальное не пережимали. Содержимое файлов почти одинаковое, за исключением этих переходов. Или две изошки - oem и retail. Они почти идентичны по содержанию. Вместе с тем, это разные файлы - разный размер и crc.

WinRAR и симлинки тут ничем не помогут, а zpaq ужмет в 2 раза.
Автор: Victor_VG
Дата сообщения: 22.01.2014 19:23
Userrr

Не вопрос - rar 5.01 (bsdrar 5.01, console/GUI rar 5.01) -> dir > list.txt

20.01.2014 11:41 284 254 00-craig_connelly-decibels-web-2014.jpg
20.01.2014 11:41 31 00-craig_connelly-decibels-web-2014.m3u
20.01.2014 11:41 948 00-craig_connelly-decibels-web-2014.nfo
20.01.2014 11:41 41 00-craig_connelly-decibels-web-2014.sfv
20.01.2014 11:41 15 373 024 01-craig_connelly-decibels.mp3
Автор: Userrr
Дата сообщения: 22.01.2014 19:26
Victor_VG, у файлов даты нормальные, я спрашивал про папку 'Craig_Connelly-Decibels-WEB-2014-TSP'
Автор: EugeneRoshal
Дата сообщения: 22.01.2014 19:27
Userrr

Цитата:
распаковывается в папку с текущей датой, хотя на самом деле 20.01.2014

В этом архиве отдельной записи для каталога нет, можете посмотреть по 'rar v zzz.rar'. Соответственно, и время каталога не хранится. А всяческие оболочки, включая список файлов в WinRAR, показывают имя каталога, извлекая его из путей файлов.

Чтобы сохранить время, при создании архива надо было упаковывать файлы вместе с каталогом.
Автор: Victor_VG
Дата сообщения: 22.01.2014 19:31
persicum

Гениально, а инкрементный бэкап, что специально для вас отменили? Как минимум связка nnbackup + rar , а о таких страшных вещах как dd и dup/restore я вообще не буду говорить - дядя Стиви & Microsoft® своим адептам думать запретил.

Добавлено:
Userrr

Понял, тут всё просто - дата создания ибо используется вызов Kernel32::CreateDirectory() и ядро ставит таймстамп создания каталога по системным часам. Так что дата в норме.
Автор: Inoz2000
Дата сообщения: 22.01.2014 19:38
в архиве у этой папки нет даты изменения. #

Автор: persicum
Дата сообщения: 22.01.2014 19:44
Victor_VG
Блин, для инкрементального бэкапа нужно, чтобы имена у файлов совпадали? А если у файлов все разное - имена, время, размер и даже каталоги? Ваши эти nn дупы передубы найдут и сожмут их общие фрагменты? Неверю.
Автор: Userrr
Дата сообщения: 22.01.2014 19:48
EugeneRoshal
Victor_VG
Inoz2000
спасибо, а то я уж думал у меня крыша поехала )
Автор: Victor_VG
Дата сообщения: 22.01.2014 19:52
persicum

Цитата:
Блин, для инкрементального бэкапа нужно, чтобы имена у файлов совпадали? А если у файлов все разное - имена, время, размер и даже каталоги? Ваши эти nn дупы передубы найдут и сожмут их общие фрагменты? Неверю.

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

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160

Предыдущая тема: Прога для поиска картинок в интернете.


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.