at Thu 11 of Mar 2010 22:40, Cezary Grądys wrote:

> Kris pisze:
>
>> tylko i wylacznie
>> DoubleKiller
>> szukasz wg wlasnych kryteriow
>> jak i sum crc32
>>
>
> Jak to według sum crc32? Czyli cały plik czytany, żeby stwierdzić
> różnicę, która może na 10 bajcie już jest?

Zawartość plików jest porównywana tylko wtedy, kiedy ich wielkość
jest jednakowa. Wówczas prawdopodobieństwo że ich zawartość jest
identyczna (a więc konieczność porównywania całych plików bajt
po bajcie) radykalnie rośnie. W mojej praktyce 99% czasu
działania fdupes to strata na jednakowych plikach.

I przykład jak to może wyglądać w praktyce:


~ls -l # mamy dwa bardzo duże pliki
-r--r--r-- 1 root wheel 1466035052 13 Mar 00:37 K2.avi
-r--r--r-- 1 root wheel 1466035052 22 Oct 2007 Kolja-DVD.avi

#time crc32 K* # szybkośc obliczenia crc
bb2b61ee K2.avi
bb2b61ee Kolja-DVD.avi
real 0m42.831s
user 0m7.646s
sys 0m7.237s

#time fdupes . # szybkość działania fdupes
./Kolja-DVD.avi
./K2.avi
real 5m33.525s
user 4m36.092s
sys 0m14.206s

Widać, że patent z crc jest około 8 razy szybszy.
Nawet md5 (wykluczający przypadkową zbieżność crc)
będzie pięć razy szybszy.


> Było by to dobre jakby było większość plików jednakowych i chcieli
> byśmy wśród nich jeden inny (lub kilka) znaleźć.

A jakiś przykład podobny do mojego?


--
nb