А как это сделать, мне нужен образ, но достать не получается. Подскажите как это делается.
» WinRAR (часть 2)
bar22890
Необходимо, чтобы все части (тома) были в одной папке. При распаковке архиватор сам распакует все части по очереди.
Необходимо, чтобы все части (тома) были в одной папке. При распаковке архиватор сам распакует все части по очереди.
Почему файл называется чтототам.part1(1).rar?
lvqcl
Посмотрите в документации схему именования томов. Это первый том многотомного архива.
Посмотрите в документации схему именования томов. Это первый том многотомного архива.
lvqcl
Цитата:
Видимо, какая-то программа переименовала. Например, скачивали один файл два раза, первая копия сохранилась как part1.rar, а вторая как part1(1).rar
Цитата:
Почему файл называется чтототам.part1(1).rar?
Видимо, какая-то программа переименовала. Например, скачивали один файл два раза, первая копия сохранилась как part1.rar, а вторая как part1(1).rar
EugeneRoshal
Кстати, точно! Браузеры на ядре Хрома автоматом так сохраняют если файл существует. Я и забыл про эту их особенность. У самого ведь стоит Дракон и он если файл существует молча добавляет к имени (?) и сохраняет вторую копию - это его стандартное поведение из коробки.
Кстати, точно! Браузеры на ядре Хрома автоматом так сохраняют если файл существует. Я и забыл про эту их особенность. У самого ведь стоит Дракон и он если файл существует молча добавляет к имени (?) и сохраняет вторую копию - это его стандартное поведение из коробки.
Подскажите? Можно извлечь по нормальному кусок фильма из part1.rar? Второй части нет (допустим) просто глянуть как и что... Или посмотреть плеером каким-нибудь.
maik2
ПКМ->Извлечь файлы...->Оставить на диске поврежденные файлы (скрин).
ПКМ->Извлечь файлы...->Оставить на диске поврежденные файлы (скрин).
Нужно архивировать какое-то количество файлов и папок, с разделением архивов по 3,9Гб. Выделяю файлы и папки, задаю:
1 Разделить на тома размером 3,9Гб
2 Каждый файл в отдельный архив
Получаю папки архивированные в заданных параметрах - 3,9Гб, но файлы упаковываются без разделения - каждый файл, в отдельный архив
Вопрос - как упаковать выделенные файлы и папки с разделением нужным размером.
Спасибо.
1 Разделить на тома размером 3,9Гб
2 Каждый файл в отдельный архив
Получаю папки архивированные в заданных параметрах - 3,9Гб, но файлы упаковываются без разделения - каждый файл, в отдельный архив
Вопрос - как упаковать выделенные файлы и папки с разделением нужным размером.
Спасибо.
Povor
Цитата:
У тебя WinRAR работает строго по заданным тобою опциям.
Цитата:
Получаю папки архивированные в заданных параметрах-3,9Гб, но файлы упаковываются, без разделения - каждый файл, в отдельный архив
У тебя WinRAR работает строго по заданным тобою опциям.
EugeneRoshal
Здравствуйте. Есть два вопроса.
1. При обновлении архива учитывается только дата/время создания/изменения архивируемых файлов. Однако, бывают ситуации, когда дата/время остаются прежними, но меняется содержимое файла. Реально ли добавить возможность выбора - либо дата, либо CRC?
Понимаю, что при сравнении контрольных сумм файлов в архиве и файлов на диске фактически нужно перечитать все файлы на диске. Но такая возможность будет очень не лишней, IMHO
2. Используя наилучшее сжатие режима RAR5 заметил увеличение времени архивации. Конечно, чем лучше/выше сжатие, тем больше времени оно занимает. Это естественно, а потому не безобразно.
Предлагаю Вам мысленно вернуться на много лет назад и представить размер архивов того времени.
Сейчас же, приблизительно представив время, необходимое на создание полного архива HDD размером 2...3 Тб приходишь в тихий ужас...
вопрос: можно ли надеяться/ожидать реализацию функции упаковки, используя ресурсы компьютеров, подключенных по локальной сети ?
Пример: многие видеоредакторы/кодировщики позволяют кодировать видео, распределяя задачу между многими компьютерами (клиен-серверная реализация ?).
На моей памяти ни один архиватор не поддерживает такую возможность... Вы будете первый...
Спасибо
Здравствуйте. Есть два вопроса.
1. При обновлении архива учитывается только дата/время создания/изменения архивируемых файлов. Однако, бывают ситуации, когда дата/время остаются прежними, но меняется содержимое файла. Реально ли добавить возможность выбора - либо дата, либо CRC?
Понимаю, что при сравнении контрольных сумм файлов в архиве и файлов на диске фактически нужно перечитать все файлы на диске. Но такая возможность будет очень не лишней, IMHO
2. Используя наилучшее сжатие режима RAR5 заметил увеличение времени архивации. Конечно, чем лучше/выше сжатие, тем больше времени оно занимает. Это естественно, а потому не безобразно.
Предлагаю Вам мысленно вернуться на много лет назад и представить размер архивов того времени.
Сейчас же, приблизительно представив время, необходимое на создание полного архива HDD размером 2...3 Тб приходишь в тихий ужас...
вопрос: можно ли надеяться/ожидать реализацию функции упаковки, используя ресурсы компьютеров, подключенных по локальной сети ?
Пример: многие видеоредакторы/кодировщики позволяют кодировать видео, распределяя задачу между многими компьютерами (клиен-серверная реализация ?).
На моей памяти ни один архиватор не поддерживает такую возможность... Вы будете первый...
Спасибо
KeeperArchive
По пункту 2 вам отвечу я - теоретически можно сжимать архив на скорости ОЗУ, но если суммарный объём данных и необходимых для сжатия буферов станет больше максимально доступного задаче размера ОЗУ то определяющей станет скорость работы подсистемы внешней памяти (в данном случае дисковой) и даже кластер суперЭВМ с самими призводительными ЦП не ускорит задачу из-за чтения данных с медленной внешней памяти.
Я ещё в 94-м году отвечал на подобный вопрос одного из банков - они хотели бэкапить всю дисковую подсистему сервера DEC AlphaSERVER 10000 AXP (13 Тб), но времени это занимало... Их идея была проста - кластер из нескольких серверов и архивация в ОЗУ. Но у данного сервера предельный объём ОЗУ 14 Гб, и даже 12 ЦП DEC Alpha AXP 21064A @ 275 MHz (тогда это были самые мощные из промышленно выпускавшихся ЦП) в каждой процессорной стойке не смогли бы ускорить решение задачи. Это при условии что для соединения узлов кластера используются каналы с пропускной способностью большей чем суммарный пиковый трафик порождаемый в кластере.
По пункту 2 вам отвечу я - теоретически можно сжимать архив на скорости ОЗУ, но если суммарный объём данных и необходимых для сжатия буферов станет больше максимально доступного задаче размера ОЗУ то определяющей станет скорость работы подсистемы внешней памяти (в данном случае дисковой) и даже кластер суперЭВМ с самими призводительными ЦП не ускорит задачу из-за чтения данных с медленной внешней памяти.
Я ещё в 94-м году отвечал на подобный вопрос одного из банков - они хотели бэкапить всю дисковую подсистему сервера DEC AlphaSERVER 10000 AXP (13 Тб), но времени это занимало... Их идея была проста - кластер из нескольких серверов и архивация в ОЗУ. Но у данного сервера предельный объём ОЗУ 14 Гб, и даже 12 ЦП DEC Alpha AXP 21064A @ 275 MHz (тогда это были самые мощные из промышленно выпускавшихся ЦП) в каждой процессорной стойке не смогли бы ускорить решение задачи. Это при условии что для соединения узлов кластера используются каналы с пропускной способностью большей чем суммарный пиковый трафик порождаемый в кластере.
KeeperArchive
1) если crc изменилось, а время модификации нет, то скорее всего файл повредился или заразился. Сомнительная фича. Может, криптоконтейнеры?
2) для архивирования целых винтов основным источником экономии места будет не сжатие файлов, а тупые повторы - дедупликация. Для дедупликации есть архиватор zpaq - я сейчас с ним балуюсь. Если архив уже создан, то добавление к нему измененной версии будет происходить вообще мгновенно, так как пропишется только diff, да и то в конец припишется и все.
Ща взял случайную папку 3G и обработал по умолчанию rar и zpaq. -))
rar a -r -s test - получилось 1.9G
zpaq a test * - получилось 0.9G - причем шустренько -)))
Дело тут конечно не в лучшем сжатии, а в дедупликации. Значит, были повторы внутри файлов.
1) если crc изменилось, а время модификации нет, то скорее всего файл повредился или заразился. Сомнительная фича. Может, криптоконтейнеры?
2) для архивирования целых винтов основным источником экономии места будет не сжатие файлов, а тупые повторы - дедупликация. Для дедупликации есть архиватор zpaq - я сейчас с ним балуюсь. Если архив уже создан, то добавление к нему измененной версии будет происходить вообще мгновенно, так как пропишется только diff, да и то в конец припишется и все.
Ща взял случайную папку 3G и обработал по умолчанию rar и zpaq. -))
rar a -r -s test - получилось 1.9G
zpaq a test * - получилось 0.9G - причем шустренько -)))
Дело тут конечно не в лучшем сжатии, а в дедупликации. Значит, были повторы внутри файлов.
Povor 21-01-2014
Если переложить файлы в папку, то получим на выходе нужную структуру архивов - файлы попадут в одни архивы, а вспомогательные данные в другие. http://iceimg.com/EElrltEU/r.png
Странно, что такая очевидность сразу не пришла мне в голову
Если переложить файлы в папку, то получим на выходе нужную структуру архивов - файлы попадут в одни архивы, а вспомогательные данные в другие. http://iceimg.com/EElrltEU/r.png
Странно, что такая очевидность сразу не пришла мне в голову
KeeperArchive
Цитата:
Реально. Не исключаю в будущем, хотя задача довольно редкая.
Цитата:
Вот это очень вряд ли. Слишком трудоемко, причем в итоге можем упереться в пропускную способность сети.
Цитата:
У меня, как пользователя, та же задача. Решение: выделить объемные файлы, которые никогда не меняются, например, iso из msdn, сбэкапить их один раз и исключить из регулярного бэкапа. Исключить мусорные временные файлы типа precompiled headers, если такие есть. Все плохо жмущееся типа архивов, jpg, avi, прописать в "Files to store without compression" или в ключе -ms. Использовать не наилучшее сжатие, а самое быстрое. Наилучшее нужно для обмена файлами, для распространения файлов, но для большого регулярного бэкапа важнее скорость.
persicum
Цитата:
Конечно, у разных пользователей и данные разные, но по моим наблюдениям все большую долю в объеме данных среднестатистического пользователя получают фото и видео. Я имею в виду уникальные данные, произведенные самим пользователем. Именно они, как правило, регулярно бэкапятся, так как остальное можно скачать заново. И в структуре таких данных сейчас заметный перевес в сторону фоток и домашнего видео просто в силу их большого размера. А для них дедупликация мало что даст, тут просто надо включать "store" или "fastest" сжатие.
Цитата:
Можно включить rar5 и словарь хотя бы в 32мб.
Цитата:
Реально ли добавить возможность выбора - либо дата, либо 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мб.
KeeperArchive 23:06 21-01-2014
Цитата:
+1
persicum 05:34 22-01-2014
Цитата:
EugeneRoshal 09:51 22-01-2014
Цитата:
Не факт, что повредился, и задача не так чтобы уж сильно редкая.
Некоторые текстовые редакторы (например, знаменитый Akelpad , UltraEdit и другие) и графические программы (например, знаменитый IfranView) имеют штатную опцию: "сохранять оригинальное время модификации" (при сохранении на диск изменённого файла). А в некоторых случаях приходится даже руками восстанавливать оригинальное время модификации после изменения. Когда и почему это необходимо, объяснять не буду, ибо офф-топ. Но, поверьте, это реально нужно, и этом многие пользуются. Так что задача, поставленная KeeperArchive, отнюдь не экзотическая.
Другое дело, что в таких случаях в результате редактирования обычно изменяется размер файла. Так что, можно бы ограничиться проверкой совпадения размера. Но ведь может совпасть и так, что в результате редактирования файла размер случайно останется тот же самый.
Цитата:
При обновлении архива учитывается только дата/время создания/изменения архивируемых файлов. Однако, бывают ситуации, когда дата/время остаются прежними, но меняется содержимое файла. Реально ли добавить возможность выбора - либо дата, либо CRC?
+1
persicum 05:34 22-01-2014
Цитата:
1) если crc изменилось, а время модификации нет, то скорее всего файл повредился или заразился. Сомнительная фича
EugeneRoshal 09:51 22-01-2014
Цитата:
Реально. Не исключаю в будущем, хотя задача довольно редкая.
Не факт, что повредился, и задача не так чтобы уж сильно редкая.
Некоторые текстовые редакторы (например, знаменитый Akelpad , UltraEdit и другие) и графические программы (например, знаменитый IfranView) имеют штатную опцию: "сохранять оригинальное время модификации" (при сохранении на диск изменённого файла). А в некоторых случаях приходится даже руками восстанавливать оригинальное время модификации после изменения. Когда и почему это необходимо, объяснять не буду, ибо офф-топ. Но, поверьте, это реально нужно, и этом многие пользуются. Так что задача, поставленная KeeperArchive, отнюдь не экзотическая.
Другое дело, что в таких случаях в результате редактирования обычно изменяется размер файла. Так что, можно бы ограничиться проверкой совпадения размера. Но ведь может совпасть и так, что в результате редактирования файла размер случайно останется тот же самый.
Цитата:
Цитата:
>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 файла он про это говорит (если дать нужную команду).
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}
думаю что из приведённых соотношений всё понятно.
Ну, есть вообще элементарное решение - хардлинки на дублирующиеся файлы. Консоли не боитесь? Если не боитесь, то воспользуйтесь утилитой 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}
думаю что из приведённых соотношений всё понятно.
Victor_VG
Цитата:
Давно пользуюсь для этого утилитой fdf от автора imdisk:
http://www.ltr-data.se/opencode.html/
рекомендую
Цитата:
Ну, есть вообще элементарное решение - хардлинки на дублирующиеся файлы. Консоли не боитесь? Если не боитесь, то воспользуйтесь утилитой hdlink: HardLink duplicate files 32x64 v1.15 написанной Андреем Гречкиным.
Давно пользуюсь для этого утилитой fdf от автора imdisk:
http://www.ltr-data.se/opencode.html/
рекомендую
что за хитрый архив?
распаковывается в папку с текущей датой, хотя на самом деле 20.01.2014
Добавлено:
как можно его распаковать с правильной датой?
распаковывается в папку с текущей датой, хотя на самом деле 20.01.2014
Добавлено:
как можно его распаковать с правильной датой?
Ajaja
Таких утилит есть множество, к примеру dupemerge и ln от Gerhild Schinagl и Hermann Schinagl, просто не все ими пользуются и чаще всего просто по незнанию об их существовании...
Таких утилит есть множество, к примеру dupemerge и ln от Gerhild Schinagl и Hermann Schinagl, просто не все ими пользуются и чаще всего просто по незнанию об их существовании...
Victor_VG
Речь идет о данных, продублированных скрытым образом -)). Например, есть оригинальный видеофайл и видеофайл, куда вы вставили несколько переходов, остальное не пережимали. Содержимое файлов почти одинаковое, за исключением этих переходов. Или две изошки - oem и retail. Они почти идентичны по содержанию. Вместе с тем, это разные файлы - разный размер и crc.
WinRAR и симлинки тут ничем не помогут, а zpaq ужмет в 2 раза.
Речь идет о данных, продублированных скрытым образом -)). Например, есть оригинальный видеофайл и видеофайл, куда вы вставили несколько переходов, остальное не пережимали. Содержимое файлов почти одинаковое, за исключением этих переходов. Или две изошки - oem и retail. Они почти идентичны по содержанию. Вместе с тем, это разные файлы - разный размер и crc.
WinRAR и симлинки тут ничем не помогут, а zpaq ужмет в 2 раза.
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
Не вопрос - 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
Victor_VG, у файлов даты нормальные, я спрашивал про папку 'Craig_Connelly-Decibels-WEB-2014-TSP'
Userrr
Цитата:
В этом архиве отдельной записи для каталога нет, можете посмотреть по 'rar v zzz.rar'. Соответственно, и время каталога не хранится. А всяческие оболочки, включая список файлов в WinRAR, показывают имя каталога, извлекая его из путей файлов.
Чтобы сохранить время, при создании архива надо было упаковывать файлы вместе с каталогом.
Цитата:
распаковывается в папку с текущей датой, хотя на самом деле 20.01.2014
В этом архиве отдельной записи для каталога нет, можете посмотреть по 'rar v zzz.rar'. Соответственно, и время каталога не хранится. А всяческие оболочки, включая список файлов в WinRAR, показывают имя каталога, извлекая его из путей файлов.
Чтобы сохранить время, при создании архива надо было упаковывать файлы вместе с каталогом.
persicum
Гениально, а инкрементный бэкап, что специально для вас отменили? Как минимум связка nnbackup + rar , а о таких страшных вещах как dd и dup/restore я вообще не буду говорить - дядя Стиви & Microsoft® своим адептам думать запретил.
Добавлено:
Userrr
Понял, тут всё просто - дата создания ибо используется вызов Kernel32::CreateDirectory() и ядро ставит таймстамп создания каталога по системным часам. Так что дата в норме.
Гениально, а инкрементный бэкап, что специально для вас отменили? Как минимум связка nnbackup + rar , а о таких страшных вещах как dd и dup/restore я вообще не буду говорить - дядя Стиви & Microsoft® своим адептам думать запретил.
Добавлено:
Userrr
Понял, тут всё просто - дата создания ибо используется вызов Kernel32::CreateDirectory() и ядро ставит таймстамп создания каталога по системным часам. Так что дата в норме.
в архиве у этой папки нет даты изменения. #
Victor_VG
Блин, для инкрементального бэкапа нужно, чтобы имена у файлов совпадали? А если у файлов все разное - имена, время, размер и даже каталоги? Ваши эти nn дупы передубы найдут и сожмут их общие фрагменты? Неверю.
Блин, для инкрементального бэкапа нужно, чтобы имена у файлов совпадали? А если у файлов все разное - имена, время, размер и даже каталоги? Ваши эти nn дупы передубы найдут и сожмут их общие фрагменты? Неверю.
EugeneRoshal
Victor_VG
Inoz2000
спасибо, а то я уж думал у меня крыша поехала )
Victor_VG
Inoz2000
спасибо, а то я уж думал у меня крыша поехала )
persicum
Цитата:
А вот с этим к святым отцам пожалуйста - вера это по их департаменту, а факты по моему. Идите и покурите маны - вам это срочно нужно.
Цитата:
Блин, для инкрементального бэкапа нужно, чтобы имена у файлов совпадали? А если у файлов все разное - имена, время, размер и даже каталоги? Ваши эти nn дупы передубы найдут и сожмут их общие фрагменты? Неверю.
А вот с этим к святым отцам пожалуйста - вера это по их департаменту, а факты по моему. Идите и покурите маны - вам это срочно нужно.
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
Предыдущая тема: Прога для поиска картинок в интернете.
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.