Dotaz: sort --non-unique

[miso]

Ahoj, snazil som sa prehladat miestne fora, ale nejako som nenasiel riesenie svojho problemu, aj ked mam pocit ze to niekde (mozno to nebol tento server) pisal yeti.
Chcel by som riesit problem pri kopirovani fotiek z fotaku na disk. Niekedy prekopirovane fotky nezmazem a fotim dalej. Pri dalsom kopirovani mi vznika duplicita. Proste by som rad mal skript, ktory zmaze pri duplicite suborov ten novsi. Pre zaciatok som si vypisal md5-ky vsetkych suborov : find -P ~/fotky/ -type f|xargs md5sum. Chcel by som nejakym sposobom vyfiltrovat len riadky, kde nieje jedinecne md5. Snad rozdiel medzi vystupom a sort-u.Potom to budem riesit dalej. Principialne veci ako rychlost a vynechanie starych adresarov prosim neriesit.
Dakujem

Odpovědi

[Heron]

man uniq

[miso]

diky, vyzera zaujimavo
medzitym som to uz vyriesil (poradil mi kamarat) s awk

[Heron]

Není zač. Dáš sem to řešení, nebo se někdo další zeptá na to samé v budoucnosti, protože to nenajde?

[miso]

Takze moj vysledok je tu :
for file in $(find -P ~/fotky -type f -exec md5sum '{}' \;|awk '{ sum[$1]++ ;path[$1]=$2 } END {for (meno in sum) if (sum[meno] == 2) print path[meno]}');
do rm -f $file && echo "Delete redundant file $file";done

[Jan Martinek]

Jestli tomu dobře rozumím, tak tento skriptík nesplňuje požadavek, aby při duplicitě souborů mazal ten novější. Navíc nebude fungovat, když v názvu souboru budou mezery. Krom toho počítá md5 úplně ze všech souborů, což je zbytečné a pomalé. Stačí zkontrolovat jen ty, které mají stejnou velikost. Napsal jsem tedy tohle:

#!/usr/bin/env python
import os,md5

def CalcMD5(filename):
  buffersize = 1000000
  sum = md5.new()
  f = open(filename)
  while True:
    data = f.read(buffersize)
    if not data: break
    sum.update(data)
  f.close()
  return sum.hexdigest()
 

def removefile(name):
  print 'removing', name
# os.remove(name)

def removeduplicit(filelist):
  md5sums = {}
  for name in filelist:
    sum = CalcMD5(name)
    if not md5sums.has_key(sum):
      md5sums[sum] = name
      continue

    name1 = md5sums[sum]
    name2 = name
    print 'duplicit files: ', name1, name2
    if os.path.getctime(name1) > os.path.getctime(name2):
      removefile(name1)
      md5sums[sum] = name2
    else:
      removefile(name2)

 
path = '.'

sizes = {}
for root, dirs, files in os.walk(path):
  for file in files:
    name = os.path.join(root, file)
    if not os.path.isfile(name): continue
    size = os.path.getsize(name)
    if sizes.has_key(size):
      sizes[size].append(name)
    else:
      sizes[size] = [name]


for k in sizes.keys():
  if len(sizes[k]) > 1:
    removeduplicit(sizes[k])

Nejprve najde soubory, které mají stejnou velikost a teprve z nich počítá md5sum. Když najde duplicitu, smaže ten novější. Namátkou jsem to zkusil na jednom adresáři a vychází to asi desetkrát rychlejší než ten skript v BASHi.

[miso]

Chvilku potrva, nez to 'preluskam' , ale urcite je to vyborny napad pozerat najprv na velkost. Dik

[trancelius]

A co rsync ?

rsync -avz /mnt/fotak/ /home/miso/fotky/

[miso]

V tom je prave problem, ze fotak pomenovava fotky inkrementalne.
Ak by som ich vo fotaku zmazal, tak nove budu mat rovnake nazvy ako predchadzajuce, preto je pre mna dolezity md5sum.
Okrem toho sa to dost miesa (viac fotakov, viac kompov). Zatial som sa dopracoval k tomuto :
find -P ~/fotky/ -type f -exec md5sum '{}' \;|awk '{ sum[$1]++ } END {for (meno in sum) if (sum[meno] == 2) print meno}'
V konecnom dosledku chcem, aby sa mi po pripojeni fotaku spustil skript, ktory skopiruje len jedinecne fotky a ostatne ignoruje.
Zrejme si md5 budem zapisovat do suboru (sqlite?).
Trosku sa este pohram s awk (nie som velky expert ) aby som ziskal druhy stlpec miesto prveho.

[Hynek (Pichi) Vychodil]

Proboha, co to máš za foťák? Moje E-10 umí inkrementálně číslovat fotky pořád kupředu levá, bez ohledu na nějaké mazání nebo jiné skopičiny. Jedna fotka má své vlastní unikátní číslo a možná za pár tisíc let se začnou opakovat. Pak to možná začnu řešit. Co kdyby jsi si raději přečetl manuál k foťáku a našel kde se to zapíná v tom tvém? Aneb jak dělat jednoduché věci složitě. Mimo to jsem obdonou úlohu řešil v perlu, ale tam šlo o stejné soubory různého jména a ještě jsem k tomu musel sledovat inody kvůli hardlinkům.

[miso]

Pisal som ze fotakov je viac - mam kamaratov s Olympus C-740/765 a este jeden typ(nepamatam) - rovnaky format nazvov, okrem toho mam fotky na CD a sice mi to inkrementuje, ale pri nabijani v nabijacke (vybrati bateriek na niekolko hodin) sa pocitanie zresetuje a po zalozeni bateriek to NECHEM nastavovat (fotak pouziva aj moja manzelka a NEBUDE to riesit). Takze tak s tymi skopicinami.
Proste chcem si chcem ku kompu pripojit fotak alebo CD a skopirovat si len nove fotky, alebo vsetky a dodatocnym skriptom v nich spravit poriadok.
To ze si obdobnu ulohu riesil - dakujem za informaciu
P.S. : Moja odpoved nieje myslena arogantne, proste to chcem vyriesit prave takto

[miso]

ospravedlnujem sa
to, ze zdrojov s rovnakou konvenciou nazvov je viac som tu predtym nenapisal -(
btw - este som nezazil tolko prispevkov na moj dotaz

[Jan Martinek]

Mě se zdá, že počítání md5 součtu je celkem zbytečný krok. Co třeba nějak takhle?
cmp -s file1 file2 && echo 'files are identical'

[Heron]

Porovnání md5sumy (32B) je daleko rychlejší, než porovnávat 2MB soubory. Nehledě na to, že vyhledání identických prvků v seznamu má kvadratickou složitost (pro 100 fotek bych skutečně nechtěl až 10000x porovnávat soubory).

[Jan Martinek]

Porovnání md5sumy (32B) je daleko rychlejší, než porovnávat 2MB soubory.

Jenže k vytvoření md5sum je potřeba oba soubory nejprve přečíst. A když už se čtou, tak je lepší je rovnou porovnávat. Jinou situací by bylo, kdyby se součty uchovávaly.

Nehledě na to, že vyhledání identických prvků v seznamu má kvadratickou složitost (pro 100 fotek bych skutečně nechtěl až 10000x porovnávat soubory).

Jo, to mi došlo v okamžiku, kdy jsem odeslal svůj předchozí příspěvek. Samozřejmě, beru to zpět a jako bych nic neříkal

[miso]

Ale ved to sa v tom skripte riesi.
Hodnoty sa uchovavaju, pretoze sa hlada duplicita.

[Jan Martinek]

Ale ved to sa v tom skripte riesi.
Hodnoty sa uchovavaju, pretoze sa hlada duplicita.

Kdepak. Skript po ukončení všechny md5 součty zapomene - nikam si je neukládá. Takže při každém spuštění musí každý soubor znovu přečíst. A já jsem tvrdil, že místo počítání md5 je rychlejší ty soubory přímo porovnávat. Ale můj argument platí pouze pro dva soubory, nikoli pro větší počet (viz Heronův komentář).
Dál bych se k tomu nevracel - souhlasím s tím, že kontrolní součty se počítat musí.

[miso]

Jasne, teraz som napisal ja blbost
Mal som na mysli ze sa uchovavaju pocas porovnavania.
Inac toto je len cast, v uvode som pisal ze to chcem robit prave tak, md5 si pamatat v sqlite (databaza z dovodu oznacovania obrazkov pre export na web).
A porovnavat budem fotky z disku "mladsie ako par dni" (hodnotu este neviem) oproti databaze + fotky v pripojenom fotaku oproti databaze.
Jasne, uz to nechajme , dakujem zucastnenym

[trancelius]

A já jsem tvrdil, že místo počítání md5 je rychlejší ty soubory přímo porovnávat.

A důkaz máte ? Proč myslíte, že něco jako kontrolní součet existuje ? Právě proto, aby se nemusely porovnávat soubory celé. Je mnohem méně náročné udělat ze dvou souborů sumy a ty porovnat, než porovnávat dva soubory blok po bloku. Jestli chcete, ověřte si to experimentálně:

# nejdřív údajně "rychlejší" přímé srovnání
$ time cmp 200M.file 500M.file

real    0m36.040s
user    0m3.212s
sys     0m0.992s

# a teď ta "pomalejší" metoda
$ time md5sum 200M.file; time 500M.file xcom.isp
173d175343421da0336770946587dcb4  200M.file

real    0m2.793s
user    0m1.280s
sys     0m0.380s
677b7d80c9d71ab984ce3cbdfa59cc84  500M.file

real    0m5.435s
user    0m1.332s
sys     0m0.392s

Takže ?

[trancelius]

oprava, ten druhý příkaz je

$ time md5sum 200M.file; time md5sum 500M.file

nějak se mi do toho zamíchala práce vedle...

[Jan Martinek]

Já jsem dostal výsledky opačné:

$ time cmp file1-20MB file2-20MB

real    0m0.318s
user    0m0.220s
sys     0m0.068s
$ time md5sum file1-20MB; time md5sum file2-20MB
13d9f78c4116943ac63cc6b0ed045f9a  file1-20MB

real    0m0.241s
user    0m0.176s
sys     0m0.052s
13d9f78c4116943ac63cc6b0ed045f9a  file2-20MB

real    0m0.258s
user    0m0.180s
sys     0m0.044s

Zkusím to nějak shrnout:
Příkaz cmp čte soubory "na střídačku", po blocích, takže disk hodně seekuje, proto je to pomalé. Přímé porovnání bloků je rychlejší operace než výpočet md5 součtu (doufám, že se na tom shodneme). Takže záleží na velikosti souboru.
Další věc je, že máme asi jiné příkazy cmp, protože u mě skončí ihned, když se porovnávané soubory liší délkou (což je v praxi celkem častý případ). Krom toho odlišné soubory není nutné přečíst celé, stačí pouze do výskytu prvního rozdílu. Zapomněl jsem na něco?
Musím ale uznat, že md5sum je rychlejší než jsem si myslel.

[trancelius]

Nějak tak ... md5 dostává náskok až u větších souborů :) a ten cmp - je to z Debian Woody, asi trochu starej...

[Michal Marek (twofish)]

Takže zopakuj test s cmp -s.

Právě proto, aby se nemusely porovnávat soubory celé. Je mnohem méně náročné udělat ze dvou souborů sumy a ty porovnat,

Jak velká část souboru se asi načte při počítání md5? (hint: 100%)

[trancelius]

Takže zopakuj test s cmp -s

Jak by podle tebe mohlo potlačení výstupu (-s, -q, --silent nebo --quiet) ovlivnit rychlost této operace (snad kromě několika mikrosekund, které jsou potřeba na vygenerování a vypsání výstupu) ??

Jak velká část souboru se asi načte při počítání md5? (hint: 100%)

Porovnávání dvou (velkých ...) souborů znamená načíst kousek souboru 1, kousek souboru 2, porovnat, zahodit ... a tak pořád dokola; při tvorbě hashe se načítají jen n-té bajty ze souboru a z nich se počítají hashe, v paměti se nikdy nemanipuluje s takovými objemy dat.

P.S.: Přesto jsem udělal test i s volbou -s, výsledek byl řádově stejný (cmp kolem 1 minuty, md5sum 5 sekund)

[Michal Marek (twofish)]

Jak by podle tebe mohlo potlačení výstupu (-s, -q, --silent nebo --quiet) ovlivnit rychlost této operace (snad kromě několika mikrosekund, které jsou potřeba na vygenerování a vypsání výstupu) ??

Rychlost operace to ovlivní docela zásadně, protože nemusí zjišťovat kde se ty soubory liší. U různě velkých souborů tedy skončí hned jak zjistí jejich velikost.

při tvorbě hashe se načítají jen n-té bajty ze souboru a z nich se počítají hashe

Bavíme se o md5, takže tohle je nesmysl.

[trancelius]

z man cmp:

       -s  --quiet  --silent
              Output nothing; yield exit status only.

Mohl bys mi vysvětlit, jak to souvisí se samotným procesem porovnávání ? Tahle volba ovlivňuje jen standardní výstup, jestli to vypíše "Soubory jsou shodné" nebo jen vrátí nulu.

[Michal Marek (twofish)]

Better to keep your mouth shut and be thought a fool than to open it and remove all doubt.

Aby vypsal, na kterém bajtu se soubory liší, musí je přečíst aspoň po ten bajt, i když jsou jinak velké a je od začátku jasné, že se budou lišit.

$ ls -1sh f1 f2
232M f1
314M f2
$ strace cmp -s f1 f2
...
open("f1", O_RDONLY|O_LARGEFILE)        = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=242081792, ...}) = 0
open("f2", O_RDONLY|O_LARGEFILE)        = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=328479232, ...}) = 0
_llseek(3, 0, [0], SEEK_CUR)            = 0
_llseek(4, 0, [0], SEEK_CUR)            = 0
exit_group(1)                           = ?

[trancelius]

Udělal jsem ltrace na té verzi co mám já (GNU diffutils 2.1) a oba výpisy byly téměř shodné ... takže to v této verzi ještě nebylo :( sorry

[Jan Martinek]

Aj! Díky, taky jsem zapomněl na to "-s". Takže oprava:

$ time cmp -s file1-20MB file2-20MB

real    0m0.155s
user    0m0.008s
sys     0m0.120s

[trancelius]

Odlišnost výsledků s volbou -s je způsobená spíš náhodou ... třeba zrovna byl disk míň vytíženej atd. Zkus ten příkaz 10x a pak to zprůměruj :)

[Jan Martinek]

Nemá cenu srovnávat různé verze cmp. Ale v mém případě tam rozdíl je. Pustil jsem 10x cmp a vybral vždy nejrychlejší čas.

$ time cmp  file1-20MB file2-20MB

real    0m0.369s
user    0m0.208s
sys     0m0.092s
$ time cmp -s file1-20MB file2-20MB

real    0m0.143s
user    0m0.020s
sys     0m0.104s

Ale tato debata už je celkem dost off-topic