Tak sie zastanawiam, czy sobie czegoś takiego samemu nie napisać - ale może
to już jest? Może jest już programik o takiej funkcjonalności (dla MS
Windows)?

Jak to ma działać?

Wkładam pendrive a program skanuje określone zasoby komputera (cały albo
jakiś folder, foldery, może otoczenie itd.) i sprawdza: które z plików na
pendrive są także gdzieś indziej niż na tym pendrive?

Dla jednego pliku - to trywialne. Dla paru? Nie wiem czy zrobienie listy w
rodzaju DSC0123.jpg;DSC3242.jpg;DSC3255.jpg dla np. 50 plików ma sens - choć
teoretycznie to możliwe. W dodatku takie wpisywanie w "szukaj" raczej
wygodne nie jest. A ma działać od XP w górę.

Ciągle łapię się na tym, że na pendrive mam pliki, które nie wiem czy są
gdziekolwiek indziej - czy też zostały wrzucone tam na chwilę, bo akurat
chciałem np. wydrukować je w jakimś samoobsługowym fotolabie?

do góry

On Thu, 15 Jul 2010 22:25:53 +0200, "slawek" <s...@h...pl> wrote:

>Tak sie zastanawiam, czy sobie czego? takiego samemu nie napisać - ale może
>to już jest? Może jest już programik o takiej funkcjonalno?ci (dla MS
>Windows)?

petla po wszystkich plikach w lokalizacja A
find pliku w B

Koniec pogramu. Find jest w linuxie poleceniem systemowym, for jest
konstrukcja wbudowana w shella.

Pod winda w najgorszym przypadku sciagnij cygwina.

milego dnia, hej
--
Moja wyprzedaz wszystkiego: ksiazki, plyty, filmy.
http://www.garaz.pol.pl/

do góry

Użytkownik "Maciej Pilichowski" <P...@g...com>
napisał w wiadomości grup
dyskusyjnych:1hpv36lu6i88k0cpkcvrc5ta423u8khmdl@4ax.
com...
> petla po wszystkich plikach w lokalizacja A
> find pliku w B
>
> Koniec pogramu. Find jest w linuxie poleceniem systemowym, for jest
> konstrukcja wbudowana w shella.

Zgoda, teoretycznie dobrze.

W praktyce? Find szuka po nazwach plików - a ja chcę po zawartości. Czyli
np. plik DSC0001.JPG na kluczyku jest - programik ma znaleźć że w systemie
plików (lokalne dyski, baza zawartości CD/DVD, xfs, cokolwiek) jest co
prawda plik Monisia.JPG - ale o dokładnie takiej samej co do bitu zawartości
jak DSC0001.JPG. I tak dla wszystkich plików z kluczyka, szybko, miło,
przyjemnie.

Oczywiście taki np. filedupe też potrafi - znajdzie że są zduplikowane
DSC0001.JPG i Monisia.JPG. Ale znajdzie też że są zduplikowane k01.JPG i
k02.JPG z katalogu w którym znalazł plik Monisia.JPG. Bo filedupe (nazwa
paskudna, ale ładny programik z otwartymi źródłami) szuka identycznych
plików w jakimś ich zbiorze.

Ja chcę programu, który mając zbiór1 wyszuka wszystkie takie same pliki w
zbiór2. Czyli trochę coś innego.

slawek

do góry

W dniu 2010-07-16 06:56, Maciej Pilichowski pisze:
> On Thu, 15 Jul 2010 22:25:53 +0200, "slawek"<s...@h...pl> wrote:
>
>> Tak sie zastanawiam, czy sobie czego? takiego samemu nie napisać - ale może
>> to już jest? Może jest już programik o takiej funkcjonalno?ci (dla MS
>> Windows)?
>
> petla po wszystkich plikach w lokalizacja A
> find pliku w B

To ma wysoka zlozonosc.
To w ogole jest problem tego typu programow, analizujacych pliki w
katalogach, niezaleznie od talentu programisty itd.
Robienie brutalnej petli w petli to zbrodnia.

Byłem zainteresowany windowsowym odpowiedniiem linuksowych
df --max-depth=1 (też skądinąd wolny)
znalazlem, jest jeszcze wolniejszy, ale wielowatkowy wiec mniej boli.

Prawdopodbnie mozna zaoszczedzic budujac jakas strukture danych w RAM,
lub odcinajac (w sensie heurystyki) nieistotne galezie.

Odcinanie bym widzial jesli da sie zapewnic sortowanie A i B np. po
nazwie lub innym atrybucie bedacym elementem porownania.
Jesli kursorem A poszedlem za daleko w stosunku do B, nie ma sensu isc
dalej, teraz nadganiamy B.
Ale chyba naturalny interfejs pozyskiwania zawartosci katalogu nie ma
sortowania sortowania (znam windows).

do góry

"slawek" <s...@h...pl> wrote:

> Tak sie zastanawiam, czy sobie czegoś takiego samemu nie napisać - ale może
> to już jest? Może jest już programik o takiej funkcjonalności (dla MS
> Windows)?
>
> Jak to ma działać?
>
> Wkładam pendrive a program skanuje określone zasoby komputera (cały albo
> jakiś folder, foldery, może otoczenie itd.) i sprawdza: które z plików na
> pendrive są także gdzieś indziej niż na tym pendrive?
>
> Dla jednego pliku - to trywialne. Dla paru? Nie wiem czy zrobienie listy w
> rodzaju DSC0123.jpg;DSC3242.jpg;DSC3255.jpg dla np. 50 plików ma sens - choć
> teoretycznie to możliwe. W dodatku takie wpisywanie w "szukaj" raczej
> wygodne nie jest. A ma działać od XP w górę.

Napisałem kiedyś skrypt w pythonie http://0x80.pl/shell/removedups.py
(nic nie kasuje, zostawiłem starą nazwę), działa z linii poleceń i wypluwa
listę duplikatów. Po jednokrotnym skanowaniu zapisuje na boku dane, więc
ponowne skanowanie jest szybsze. Bez problemów działa także pod Windowsami.

Najprostsze użycie:

removedups.py -o lista.txt katalog1 katalog2 katalog3

w.

do góry

slawek <s...@h...pl> napisał(a):
> Tak sie zastanawiam, czy sobie czegoś takiego samemu nie napisać - ale
> może to już jest? Może jest już programik o takiej funkcjonalności (dla
> MS Windows)?
> Jak to ma działać?
> Wkładam pendrive a program skanuje określone zasoby komputera (cały albo
> jakiś folder, foldery, może otoczenie itd.) i sprawdza: które z plików na
> pendrive są także gdzieś indziej niż na tym pendrive?
> Dla jednego pliku - to trywialne. Dla paru? Nie wiem czy zrobienie listy
> w rodzaju DSC0123.jpg;DSC3242.jpg;DSC3255.jpg dla np. 50 plików ma sens
> - choć teoretycznie to możliwe. W dodatku takie wpisywanie w "szukaj"
> raczej wygodne nie jest. A ma działać od XP w górę.
> Ciągle łapię się na tym, że na pendrive mam pliki, które nie wiem czy są
> gdziekolwiek indziej - czy też zostały wrzucone tam na chwilę, bo akurat
> chciałem np. wydrukować je w jakimś samoobsługowym fotolabie?

Przykład w PowerShellu, nazwy katalogów zahardkodowane ale można sobie
zmienić żeby były sparametryzowane.

function Get-MD5([System.IO.FileInfo] $file = $(throw 'Usage: Get-MD5
[System.IO.FileInfo]'))
{
$stream = $null;
$cryptoServiceProvider =
[System.Security.Cryptography.MD5CryptoServiceProvid
er];
$hashAlgorithm = new-object $cryptoServiceProvider
$stream = $file.OpenRead();
$hashByteArray = $hashAlgorithm.ComputeHash($stream);
$stream.Close();
trap
{
if ($stream -ne $null)
{
$stream.Close();
}
break;
}
foreach ($byte in $hashByteArray) { if ($byte -lt 16) {$result +=
"0{0:X}" -f $byte } else { $result += "{0:X}" -f $byte }}
return [string]$result;
}
$pliki1=@{}
ls -r Katalog1 | where {$_.attributes -ne "Directory"} | foreach {
$md5 = get-md5 $_
$pliki1.add($md5, $_)
}
$pliki2=@{}
ls -r Katalog2 | where {$_.attributes -ne "Directory"} | foreach {
$md5 = get-md5 $_
$pliki2.add($md5, $_)
}

$pliki1.Keys | foreach {
if ($pliki2.containsKey($_)) {
write-host $pliki1.get_item($_).fullname "="
$pliki2.get_item($_).fullname
}
}


--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 2 days, 1 hours, 2 minutes and 59 seconds

do góry

slawek wrote:

>
> Użytkownik "Maciej Pilichowski" <P...@g...com>
> napisał w wiadomości grup
> dyskusyjnych:1hpv36lu6i88k0cpkcvrc5ta423u8khmdl@4ax.
com...
>> petla po wszystkich plikach w lokalizacja A
>> find pliku w B
>>
>> Koniec pogramu. Find jest w linuxie poleceniem systemowym, for jest
>> konstrukcja wbudowana w shella.
>
> Zgoda, teoretycznie dobrze.
>
> W praktyce? Find szuka po nazwach plików - a ja chcę po zawartości. Czyli
> np. plik DSC0001.JPG na kluczyku jest - programik ma znaleźć że w systemie
> plików (lokalne dyski, baza zawartości CD/DVD, xfs, cokolwiek) jest co
> prawda plik Monisia.JPG - ale o dokładnie takiej samej co do bitu
> zawartości jak DSC0001.JPG. I tak dla wszystkich plików z kluczyka,
> szybko, miło, przyjemnie.
>
> Oczywiście taki np. filedupe też potrafi - znajdzie że są zduplikowane
> DSC0001.JPG i Monisia.JPG. Ale znajdzie też że są zduplikowane k01.JPG i
> k02.JPG z katalogu w którym znalazł plik Monisia.JPG. Bo filedupe (nazwa
> paskudna, ale ładny programik z otwartymi źródłami) szuka identycznych
> plików w jakimś ich zbiorze.
>
> Ja chcę programu, który mając zbiór1 wyszuka wszystkie takie same pliki w
> zbiór2. Czyli trochę coś innego.
>
> slawek


Policz md5 wszystkich plikow na pendrivie i dysku i potem poszukaj takich
samych wartosci (te sumy powinny sie zmiescic w pamieci, zwykle na dysku
jest mniej niz 1mln plikow - co daje kilkanascie MB pamieci) - kazdy plik
czytasz raz. Mimo wszystko troche to potrwa.

do góry

Jacek Czerwinski nabazgrolił(a):

> Odcinanie bym widzial jesli da sie zapewnic sortowanie A i B np. po
> nazwie lub innym atrybucie bedacym elementem porownania.

W sumie skoro i tak musimy sprawdzić całe A to chyba niepotrzebne jest
całkowite porównywanie zawartości, spokojnie wystarczy sprawdzanie
skrótów jakichś X bajtów pliku i dopiero gdy to okaże się być spełnione
porównanie po kolei wielkości i w końcu zawartości plików.

Mając skrót kilkubajtowy, plus jakiś mały znacznik, o który plik chodzi
i nieprzesadną ilość plików do sprawdzenia to spokojnie całość można
w pamięci nawet trzymać. Trzeba wtedy przelecieć A i zrobić tablicę
skrótów+indeksów i tylko to posortować. Np. jeżeli skróty wielkości
dajmy na to 12 bajtów, 4 bajtowy wskaźnik/indeks pliku i z milion
plików do sprawdzenia na przenośnym to jest to raptem 16MB tablicy.
Oczywiście takie podejście to konieczność najpierw przelecenia po A
na pendrivie i zrobienia tej tablicy. Potem już tylko jechać po kolei
po wszystkich plikach B, skrót tych X bajtów, próba jego znalezienia
w posortowanej tablicy (to nic nie jest). Nie ma, to dalej, a jest to
sprawdzenie wielkości pliku i jak się zgadza to dopiero porównanie
zawartości i ew. akcja "znaleziono duplikat".

> Jesli kursorem A poszedlem za daleko w stosunku do B, nie ma sensu isc
> dalej, teraz nadganiamy B.
> Ale chyba naturalny interfejs pozyskiwania zawartosci katalogu nie ma
> sortowania sortowania (znam windows).

Tyle, że po nazwie nie ma sensu sortować, bo po zawartości porównujemy.


--
Sc0rpi0 - [...] jakiś dziwak rzucał im pocięte kawałki drutu. Powiedziałem,
że [...] nie jadają tego. -Nie zależy mi na tym, by go jadły - odparł, [...]
-Ale mogą się udławić, [...] -Nie udławią się, bo drut tonie. [...]
-Więc po co pan rzuca ? Bo lubię karmić łabędzie.

do góry