А как вам такой вариант:
Шаг первый: Берем мелкософтовский CDImage, делаем с его помощью исоху с оптимизацией.
Шаг второй: Жмем эту исоху тем же ВинРар-ом.

Архив распаковывается проще некуда, заходим сначала в рарник, потом внутри него в исоху (ВинРар понимает), и оттуда распаковываем уже то, что нужно.

Root

7zip жмет по объему так-же (если много одинаковых файлов), но гораздо медленнее по времени. Статью читал?

Добавлено спустя 2 минуты, 50 секунд:
Представь, что тебе нужно пожать, скажем 10 дистрибутивов винды (которые практически одинаковы), так ты грубо говоря потратишь 10 часов на сжатие с 7zip-ом или 1час на сжатие предархиватор+WinRar?

Все равно не ясно. Больно все общЁ. Можно узнать полный алгоритм работы ?


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

Когда следующая версия ожидается ?

Skyggedans

Минусы предложенного способа с CDimage:

1) Для распаковки потребуется не один, а два инструмента: архиватор (кто-то может захотеть использовать не Винрар, а, например, Zip ) и распаковщик ISO-образов.
Если вместо самого архиватора можно (даже нужно) воспользоваться его SFX-модулем (создать самораспаковывающийся архив), то SFX-модули для распаковки ISO-образов мне еще не встречались

2) Корректность работы Winrar'а при распаковке ISO-образов лично у меня вызывает некоторые сомнения -- пару лет назад был случай, когда этот архиватор не смог нормально извлечь содержимое одного образа.
Вполне допускаю, что с тех пор поддержка винраром формата ISO улучшилась. Но все равно лучше поискать специализированное средство.

xKVtor

Дак как-же не ясно?
Короче для начала проходит поиск и добавление в таблицу всех файлов, имеющихся в указанном каталоге. (добавляется имя, размер, путь и т.д.)
Далее проходит сравнение первого файла со вторым, третьим, ..., n-тым
потом второго с третьим, четвертым ну и т.д.
Сравнение заключается в последовательной проверке заданных условий. В случае по дефолту сначала сравнивается размер файлов, если размеры равны, то продолжаем сравнение, иначе берем следующий файл.
Далее сравниваем по имени, система та-же: имена совпадают->сравниваем по CRC, нет - берем следующий файл.

И чтоже смутного в имени, размере и CRC файла
А насчет исчезновения - чтож пусть будет только размер и побайтное сравнение...

Она будет, ее не может небыть
Если серьезно - сказал-же как получиться, у меня курсовики, экзамены, работа, я что ЮЦезарь, чтобы одновременно проги клепать, экзамены сдавать и еще умудряться работать.
Вобщем процесс идет

Lord_of_Darkness
а какая разница что жать ИСОшку на 500МБ или то же кол-во дубликатов? (это я про предложение Skyggedans). тем более, что исоха - ФС, так что там есть неприятные накладные расходы на ее организацию.

Добавлено спустя 7 минут, 32 секунды:

надо возможность отсеивать дубликаты по имени вывести в одну опцию. А может у меня есть файлы с разными именами, но одинаковым содержимым. Поэтому, ИМХО, надо сделать достаточно "умный" алгоритм с различными возможностями узнавания дубликатов.
Скажем, для меня, вполне достаточный алгоритм:
1) сортируем файлы по размерам
2) внутри каждой группы считаем CRC
3) как-то определяем файлы с одинаковым CRC и метим их как дубликаты.
Кому-то, наоборот, нужна будет возможность искать дубликаты только вреди файлов с одинаковым именем. и т.д. Моя мысль понятна?

Skyggedans

Чуть не забыл самый главный минус:

3) Современные архиваторы (прежде всего WinRAR) оптимизированы на самостоятельное определение типа сжимаемого контента. Для каждого типа (текст, графика, архивы) применяются свои специализированные методы сжатия (либо вообще сжатие не применяется, например, для архивов и jpeg-файлов). Ориентиром служит прежде всего расширение файлов (возможно еще и их заголовок). Так же расширения файлов используется при создании SOLID архивов.

Поместив ВСЕ файлы в ОДИН ISO-образ мы лишаем архиватор свободы маневра и эффективность его работы резко падает.

Root

Насколько я понимаю, CDimage -- эта та утилита, которая как раз позволяет избавиться от дубликатов на компашке.

Слышал, одно время был популярен компакт (созданный с помощью этой или ей подобной тулзы) с 3-мя операционными системами на нем (кажись, W2K WS+Server+AdvancedServer, сам я его в руках не держал). Физический объем компашки был равен 700Mb, а объем его содержимого превышал полтора гига. Суть решения та же, что и у предархиватора: одинаковые по содержанию файлы логически присутствовали в разных каталогах, а физически на компакте были представлены лишь в одном экземпляре. Т.е. несколько логических ссылок ссылались на одну физическую реализацию

Lord_of_Darkness

Между этими пунктами весьма желательно вставить сортировку списка файлов по размеру. А сравнение проводить внутри групп одинаковых по размеру файлов.
А то, что:

1) в любом случае должны (просто ОБЯЗАНЫ) присутствовать и отбор по размеру, и побайтовое сравнение. И галку с них снимать нельзя ни в коем случае ! (и возможности такой давать пользователю соответственно нельзя).

2) не ясно, отбор по одинаковому имени производится до или после отбора по размеру; в различных ситуациях "выгоднее" либо тот, либо другой вариант. "Выгоднее" в кавычках потому, что выгоднее по затраченному на поиск дубликатов времени, но никак ни по общей эффективности. Сомнительная, короче, выгода.

3) Что касается CRC, то вопрос не так прост, как может сначала показаться.

Первый (главный) недостаток CRC:

Как в этой ветке уже говорилось, по CRC нельзя судить о 100% совпадении файлов. Вероятность ошибиться мизерная, но она существует ! Поэтому в случае совпадения CRC файлов одинакового размера все равно затем потребуется провести побайтное сравнение.

Второй недостаток CRC: Чтобы его посчитать, нужно ПОЛНОСТЬЮ прочесть файл.

Кстати, на практике чаще всего получается, что если два файла не совпадают, то при побайтном сравнении их различия обнаруживаются буквально c первых нескольких [десятков] байт. Т.е. отпадает необходимость ПОЛНОСТЬЮ читать оба сравниваемых файла.

Единственное достоинство CRC: Если CRC двух одинаковых по размеру файлов не совпадает, то с вероятностью 100% можно говорить о том, что это не дубликаты, что файлы разные. Таким образом, CRC можно пользоваться, но применять ТОЛЬКО для 100%-го отсеивания файлов.

По поводу своих мыслей о применении CRC потом еще напишу несколько строк, сейчас времени нет.

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

xKVtor
у меня на винте столпотворение из hard&soft-линков Туда же и репаср пойнты В итоге, логическая структура приятная, а где лежат данные понять трудно

спорить не буду, бо стараюсь не пользоваться продуктами МС..

Добавлено спустя 9 минут, 11 секунд:
Ketsalkoatl

вот-вот. В этом вся и проблема. Когда размер словаря большой, то жмется все хорошо, но медленно (7zip solid), когда же он маленький, то жмется все быстро, но не очень хорошо (WinRAR solid). Идея в том, чтобы утрамбовать ногами данные в меньшее пространство за разумное время на определенном наборе (где много дубликатов)

Root

Для того, чтобы такие файлы нашлись, убери галку "Имя"
xKVtor

После. Все идет в том порядке в каком стоят CheckBox'ы
Ketsalkoatl

Сокращает, но совсем не на много.
To All Убрал CRC и подправил побайтное сравнение, теперь с ним все ОК (вроде)
На другие доработки времени пока нет, так что могу залить эту версию. Нада?

Добавлено спустя 8 часов, 15 минут, 42 секунды:
Залил временно эту версию.

Весьма недурственно

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

Или это опять от нехватки времени на доработку ?

Первая строчка RestoreFiles.bat:

Далее, к чему все эти HardLinks и "содержит жесткие ссылки на файлы" ? Почему не просто IncludedFiles.txt / Included.txt и "содержит полные имена файлов" ? ИМХО пользователи винды (а эта прога прежде всего для них предназначена) не поймут этой юниксоидной терминологии, как ее не понимаю и я.

xKVtor

debug version, епрст, представь, что их нет
Она хроническая

В смысле в кавычках ничего нет?

Ну напиши тогда такой ридми, который будет тебе понятен