ktos umialby napisac prostego toola, program
ktory dla podanego katalogu i podanego rozszerzenia plikow
wyszukalby pliki ktore maja binarne duplikaty i duplikaty
te przerenamowal np na koncu dodajac ciag np ".duplicate"

wywolac by to mozna np

duf pdf c:\pdfy

w jakim jezyku najlatwiej by bylo to napisac?





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

Dnia Sat, 11 Feb 2012 18:58:43 +0000 (UTC), f...@g...pl
napisał(a):

> ktos umialby napisac prostego toola, program
> ktory dla podanego katalogu i podanego rozszerzenia plikow
> wyszukalby pliki ktore maja binarne duplikaty i duplikaty
> te przerenamowal np na koncu dodajac ciag np ".duplicate"
>
> wywolac by to mozna np
>
> duf pdf c:\pdfy
>
> w jakim jezyku najlatwiej by bylo to napisac?

W każdym, a najlepiej w tym, który najlepiej się zna.:)

do góry

<f...@g...pl> napisał(a):

> ktos umialby napisac prostego toola, program
> ktory dla podanego katalogu i podanego rozszerzenia plikow
> wyszukalby pliki ktore maja binarne duplikaty i duplikaty
> te przerenamowal np na koncu dodajac ciag np ".duplicate"
>
> wywolac by to mozna np
>
> duf pdf c:\pdfy
>
> w jakim jezyku najlatwiej by bylo to napisac?
>
to jest na tyle krótkie ze mozna sie pokusic o napisanie tego
w jezyku ktorego sie nie zna

przy tym pytanie jak nalezaloby to zrobic - plikow
moglobybyc duzo (np > 100 tys) stablicowac uchwyty
z fopen czy nazwy plikow ? (czy otworzenie 100 tys
plikow nie zarzyna kompa?) czy tez mozna tego nie
tablicowac i da sie pracowac ';na zapytaniach' ?
pozniej co? posortowac tablice po rozmiarze i
zarzucic binarne porownywanie tych w ramach tego
samego rozmiaru ?








--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

f...@g...pl pisze:
> ktos umialby napisac prostego toola, program
> ktory dla podanego katalogu i podanego rozszerzenia plikow
> wyszukalby pliki ktore maja binarne duplikaty i duplikaty
> te przerenamowal np na koncu dodajac ciag np ".duplicate"
>
> wywolac by to mozna np
>
> duf pdf c:\pdfy
>
> w jakim jezyku najlatwiej by bylo to napisac?

Najprościej w shellu byłoby to napisać,
ale niestety pod Windowsem w batchu
to będzie trochę trudniej, ale jest to możliwe.
Potrzebna będzie wersja cmp for Windows
http://gnuwin32.sourceforge.net/packages/diffutils.h
tm
Dwie pętle for (dla pierwszego i drugiego pliku do porównania)
na podstawie zerowego ERRORLEVEL (nie pamiętam dokładnie nazwy)
będzie można stwierdzić, że pliki są identyczne (binarnie)
i zmienić im nazwę, na koniec należało by dodać warunek
sprawdzający istnienie porównywanych plików
(część plików może nie być już dostępna z powodu zmiany nazwy).

Pewnym mankamentem powyższego rozwiązania
będzie z pewnością wydajność, coś za coś: łatwo napisać
oraz nie jest niezbędna programistyczna wiedza.

do góry

Przy porównywaniu plików najlepiej dla każdego pliku wliczyć hash i użyć tabeli
hashującej. To jest najszybsza metoda. Jak się trafią 2 identyczne hashe - dla
pewności porównać cały plik.

do góry

On 2012-02-12 09:47, Adam Klobukowski wrote:
> Przy porównywaniu plików najlepiej dla każdego pliku wliczyć hash

Ale mam nadzieje że nie dla całego tak od razu :)

do góry

Dnia 12-02-2012 o 09:47:03 Adam Klobukowski <a...@g...com>
napisał(a):

> Przy porównywaniu plików najlepiej dla każdego pliku wliczyć hash i użyć
> tabeli hashującej. To jest najszybsza metoda. Jak się trafią 2
> identyczne hashe - dla pewności porównać cały plik.

dla sha1 chyba jeszcze nikt nie znalazł kolizji, więc można by było to
pewnie sobie darować, dla dużej ilości duplikatów mogłoby to istotnie
przyspieszyć, a jeśli nie, to koniecznie wypisywać informacje o
znalezionej kolizji: sława i bogactwo czekają ;)

md5 jest słabszy, ale jeśli dane nie będą dobierane złośliwie, to też
powinien się nadać nawet bez weryfikacji, a jest AFAIK nieco szybszy

--
Jordan Szubert

do góry

Dnia 12-02-2012 o 09:54:44 Sebastian Biały <h...@p...onet.pl>
napisał(a):

> On 2012-02-12 09:47, Adam Klobukowski wrote:
>> Przy porównywaniu plików najlepiej dla każdego pliku wliczyć hash
>
> Ale mam nadzieje że nie dla całego tak od razu :)

pohashowanie moze zredukowac zlozonosc do liniowej, jak duzo plikow, i nie
bardzo duzych, to pewnie warto
hashowanie prefiksu pliku zwieksza szanse na kolizje (np. plik sciagniety
nie do konca jest prefiksem sciagnietego calkiem)

--
Jordan Szubert

do góry

Jordan Szubert <u...@j...us.to> napisał(a):

> Dnia 12-02-2012 o 09:47:03 Adam Klobukowski <a...@g...com> =
> =
>
> napisa=B3(a):
>
> > Przy por=F3wnywaniu plik=F3w najlepiej dla ka=BFdego pliku wliczy=E6 h=
> ash i u=BFy=E6 =
>
> > tabeli hashuj=B1cej. To jest najszybsza metoda. Jak si=EA trafi=B1 2 =
>
> > identyczne hashe - dla pewno=B6ci por=F3wna=E6 ca=B3y plik.
>
> dla sha1 chyba jeszcze nikt nie znalaz=B3 kolizji, wi=EAc mo=BFna by by=B3=
> o to =
>
> pewnie sobie darowa=E6, dla du=BFej ilo=B6ci duplikat=F3w mog=B3oby to i=
> stotnie =
>
> przyspieszy=E6, a je=B6li nie, to koniecznie wypisywa=E6 informacje o =
>
> znalezionej kolizji: s=B3awa i bogactwo czekaj=B1 ;)
>
> md5 jest s=B3abszy, ale je=B6li dane nie b=EAd=B1 dobierane z=B3o=B6liwi=
> e, to te=BF =
>
> powinien si=EA nada=E6 nawet bez weryfikacji, a jest AFAIK nieco szybszy=
>
>

zdaje mi sie ze nie nalezy tu hashowac (nie znam sie zreszta na
hashowaniu)

kwestia jest tu inna: co sie wiaze z jakimi kosztami, (moje
osobiste dzialania z plikami nigdy poki co nie wykroczyly
poza zapisz wczytaj plik), np o ile mozna odpytac system
o liste plikow w katalogu (vel drzewku) w 'lity' szybki
sposob bez czytania zawartosci samych plikow to mozna
odrzucic wiekszosc (> 99%) kombinacji po samych rozmiarach -
dopiero w ramach pozostalych grup mozna sprawdzac i raczej
tez szybciej bedzie porownywac po poczatkach plikow (tez
wiekszosc odpadnie na pierwszych bajtach a te co zostana
bede juz prawie napewno duplikatami - te trzebby wtedy
sprawdzic do konca)

ale jest szereg kwestii czy jest tak jak ja to widze i czy

1) wczytywanie info o plikach z folderu (vel o calym drzewku
z podkatalogami) jest pod winda szybkie (widzac jak czasem muli
mi total komander wydaje mi sie ze cos tu jet nie tak)

2) czy przy robocie tego rodzaju (na zawartosciach folderow)
trzeba sie trzymac jakichs specjalnych zasad (typu nie otwierac
wielu plikow na raz itd)

3) czy jesli juz mialbym porownywac same poczatki to ile bajtow
poczatku najlepiej wziac do porownania

4) itd

chodzi o to ze sa na pewno jakies zasady ktore odrozniaja
dobry i szybki sposob zrobienia tego od sposobu ktory by
mulil w stosunku do pierwszego














--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 12/02/2012 09:25, Jordan Szubert wrote:
> Dnia 12-02-2012 o 09:54:44 Sebastian Biały <h...@p...onet.pl>
> napisał(a):
>
>> On 2012-02-12 09:47, Adam Klobukowski wrote:
>>> Przy porównywaniu plików najlepiej dla każdego pliku wliczyć hash
>>
>> Ale mam nadzieje że nie dla całego tak od razu :)
>
> pohashowanie moze zredukowac zlozonosc do liniowej, jak duzo plikow, i
> nie bardzo duzych, to pewnie warto
> hashowanie prefiksu pliku zwieksza szanse na kolizje (np. plik
> sciagniety nie do konca jest prefiksem sciagnietego calkiem)

Na dzień dobry bez czytania pliku jest przecież dostępna długość.

I teraz tak: mając długość pliku, można opracować algorytm biorący
ileśtam bajtów (powiedzmy maksymalnie 512) z określonej pozycji w środku
pliku i robić hash z nich.

Dodatkowy bonus jest taki, że można zapisać długość w tablicy i
porównywać ją przed binarnym porównaniem całych plików.

do góry