Fórum Root.cz
Hlavní témata => Software => Téma založeno: Honza1Ubuntu 02. 05. 2017, 12:11:10
-
Zdravim
Zkousel jsem otevrit po delsi dobe (2-4 roky) 7z archiv s vetsim mnozstvim sourobu. 7zip ale zahlasi, ze se nejedna o archiv. Kdyz jsem daval kontrolu cele slozky s velkym mnozstvim 7z archivu, par jich to naslo zkazenych. Jednotli zkazene archivy jsem zkousel otevrit-rozbalit, ale zahlasili mi to, ze se nejedna o archiv.
Pouzivam verzi 7z 16.02 (nove rekurzivni kontrolu cele slozky z archivy, omezila se i zbytecna delka vypisu pri praci). Faktem je, ze uroven komprese pri stejnem nastaveni je u nove verze mensi. Archily byly vytvareny ale starsi verzi 7z-p7zip z roku 2010.
Veskere zkazene archivy byli nejperve vytvoreny ve Windows, pak v Linuxu rozbaleny a zabaleny s vetsim slovnikem.
Divne na tom je, ze i pred lety, v dobe vytvoreni, jsem daval kontrolu archivu. Kontrola probehla uspesne tenkrat a zadnou chybu to nenaslo (tenkrat umel rekurzivni kontrolu jen GUI 7z ve Widlich).
Moznost opravy archivu tady je, i kdyz muze byt pomerne slozita. Vzhledem k slozitosti bude jednodussi vytvorit data znova (tedy az na jeden archiv, se kterym mozna zkusim neco udelat).
================================================================
Stava se vam take obcas, ze 7zip archiv nejde otevrit, hlasi to, ze se nejedna o archiv (tim nemyslim chybu "Can't allocate required memory" kdyz se slovnik nebo filelist nevejde do RAM) ?
Tedy pouceni - obcas se hodi archivy s dulezitimi daty prekontrolovat a mit vic verzi archivu.
-
Ne, nekazí. Hnije ti disk nebo se to zkurvilo při kopírování.
-
Ne, nekazí. Hnije ti disk nebo se to zkurvilo při kopírování.
Jsem víceméně stejnýho názoru. Přikláním se tedy hlavně k disku.
-
V tom případě by měla kontrola partition odhalit hnilobu v souboru
-
Chyba disku, ransomware?
-
Nemáš pokažené i jiné soubory? Od té doby co jsi archivy naposledy kontroloval, jsi je přesouval na jiný disk nebo počítač, nebo dělal defragmentaci?
Chybu disku bych netipoval. Disky mají v sektorech opravné kódy a pokud se data pokazí, tak se místo toho projeví chyba čtení sektoru. Pusť memtest, pokud najde chyby, máš příčinu skoro jasnou.
-
Co 32bit vs 64bit, kdy se snažíš více než 2GB archiv otevřít pomocí 32bit 7zip?
-
Jine soubory pokazene nemam. Jsou to jen 7z archivy, moc jich neni.
Na chybu disku to nevypada, protoze jak prekopirovani souboru jinam, tak cteni a zipis na disk jde velice svizne bez problemu. I inkriminovane archivy jde presunout z disku externiho na systemovy disk do home. Presunuti jde bez jakychkoliv zaseku, ale pak pri pokusu otevrit/rozbalit/zkontrolova archiv to zahlasi, ze se nejedna o 7z archiv.
Vse je 64 bitove, proto take lze pouzit velky slovnik. V tom to nebude. Navic takovou chybu by to zahlasilo jako "Can't allocate required memory"
Na jiny disk, pocitac soubory byly presouvany po vytvoreni. Pak ale byl disk zkontrolovan windowsackym 7zipem. Od doby kontroly soubory presouvany nebyli.
Vsechny chybne archivy maji ale jednu vec spolecnou. Byly vytvoreny ve Windows na jinem stroji a pak presunuty do home v linuxu pomoci winscp. U techto souboru ale doslo k rozbaleni a komprimaci v Linuxu s vetsim slovnikem. Takze v tom by byt problem nemel. Ne vsechny archivy puvodne z Widli to delaji, jen par ma chybu.
Navic ze serveru pak byly prez WinSCP vsechny soubory presunuty na externi disk. A to archivy jak puvodne vytvorene na serveru, tak archivy puvodne vytvorene ve windows a predelane v Linuxu. Ted je zase disk zase pod Linuxem.
Zkousel jsem jeden archiv i ze zalohy od jinud, a stejny problem. Na obou mistech pozkozeny ten samy archiv. Aktualnim diskem to nebude.
-
kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.
-
kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.
AFAIK 7zip si alokuje paměť před komprimací, takže by musel zdechnout rovnou ještě před vytvořením archivu ne během komprimace.
-
Jen nápad, pravděpodobně k ničemu, protože jste to tak dělal ...
Kde (nebo v čem) to rozbalujete? Několikrát jsem se setkal, pokud soubory měli jiné než základní ascii znaky, tak to některým systémům dělalo potíže (windows, KDE ... stručně; systémy s 16-bit znakem).
Pokud jste to nerozbaloval přímo v konzoli, tak bych to zkusil tam (locale s utf-8).
-
youarefired
Vzdycky skript archiv rozbalil, po rozbaleni byl archiv zkoprimovan a pak byl stary archiv smazan. Data znova zkomprimovany prikazem:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z
Nikdy jsem nezapioval do jiz vytvoreneho archivu jakozto aktualizace archivu, to je relativne riziko.
Chyba spravce to muze byt (server jsem zpravcoval ja).
Jestli psal do stejne pojmenovaneho rozpracovaneho souboru, to tezko rict ted. Ale mozna i ano. Kdyz se proces komprimace ukonci, vetsinou tam zadny soubor nezbyde - stihne ho 7z smazat. (a ne prikazovem radku can't allocate required memory), ale pokud se proces nahle ukonci, muze tam zbyt nedokonceny archiv se stejnym jmenem jako dokonceny (a kdyz poustis prez nohup, tak se to nedozvis).
Takovou chybu by mela odhalit kontrola stejne, i kdyz kontrola zase na Widlich mohla ignorovat souboury s prilis velkym filelist (Widle byli 32-bit)
-
ByCzech
To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.
-
Trumbera
Rozbaleno i zabaleno v p7zip v terminalu. Hacky, carky, mezery a dalsi zvladal dobre. Stejne tak i dost dlouhe nazvy souboru.
Pozkozene archivy maji min. nektere stejne jen alfa-numericke znaky a podtrzitko v nazvu. Nazvy a cesty moc dlouhe nejsou.
Podle vseho chybu odhalil youarefired
-
ByCzech
To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.
Právě jsem to vyzkoušel. Když to přeženu s velikostí slovníku, skončí to hned při startu na tuhle chybu:
ERROR: Can't allocate required memory!
-
Konverze CRLF/LF?
-
ByCzech
To prave spis ne ne - naopak spis zdechne v prubehu. Pamet VIRT si alokuje na zacaatku, a neresi moc, jestli je dostatek. Pamet RES az v prubehu a jak pamet RES stoupa, nekdy v prubehu komprimace proste zdechne.
Taky jsem to vyzkousel, a prave az po urcite dobe, kdy presahne pamet RES volne misto v RAM, to zdechne. Tedy v pripade, ze potrebna pamet je priblizne stejne velka, jako pamet, co je k dispozici. A to jak u stare, tak i nove verze. Hlaska k tomu je uplne stejna.
Kdyz je ale velikost slovniku o dost vetsi, nez co se vejde do RAM. tak to 7zip pozna a zahlasi hned na zacatku, proces se zastavi.
Takze vlastne jak kdy.
Právě jsem to vyzkoušel. Když to přeženu s velikostí slovníku, skončí to hned při startu na tuhle chybu:
ERROR: Can't allocate required memory!
-
Konverze CRLF/LF?
O zaheslovane archivy se nejedna. U tech se zepta na heslo, v pripade nohup napise jako chybu spatne heslo (pri nohup neceka na vstup).
-
kdyz komprimuje, tak pise do stejne pojmenovaneho, ale rozpracovaneho nedokonceneho souboru nebo ma pracovni jmeno? jestli jo, tak to bude nepoznatelny, kdyz to zabije oom, tak to neni vada 7zip, ale spravce.
Pravdepodobne to bude cele reseni. Pri vytvareni archivu nejak dosla pamet, coz se muze stat nahlym spustenim jineho procesu navic, i kdyz by pamet dojit nemela. &z pak pri vycerpani RAM padne. A nekdy se nesmaze rozpracovany nedodelany archiv,i kdyz by mel. A kdyz to jede prez nohup, neni poznat nic.
Rozpracovany archiv ma stejne jmeno a neni poznat ze je nedokoncen. Nektera data k archivu (filelist, typ komprese pod.) se pravdepodobne ukladaji az na konec archivu.
Pri kontrole ve Win32 s nedostatkem pameti (Pri 1024 MB slovniku je potreba je na kontrolu okoko 2,2 GB +Filelist) napsal 7z ze nestaci pamet, a tak jsem archiv ignorovoal, coz byla chyba. Dva zkazene archivy maji okolo milionu suboru, ale dalsi zkazene archivy tolik souboru nemaji.
Opravovat ma smysl mozna jeden archiv, ale asi by to vubec nebylo jednoduche, co jsem hledal.
-
A kdyz to jede prez nohup, neni poznat nic.
Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:
7-Zip returns the following exit codes:
0 Normal (no errors or warnings detected)
1 Warning (Non fatal error(s)). For example, some files cannot be read during compressing. So they
were not compressed
2 Fatal error
7 Bad command line parameters
8 Not enough memory for operation
255 User stopped the process with control-C (or similar)
-
A kdyz to jede prez nohup, neni poznat nic.
Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:
No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.
Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.
-
A kdyz to jede prez nohup, neni poznat nic.
Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:
No jo, kdyz uz si clovek myslel, ze skript funguje OK a presmeroval nohup dp /dev/null . Bez presmerovani jde vystup do nohup.out . On je ten soubor nekdy i docela velky a presmerovani do /dev/null setri systemove prostredky.
Mozna tam i nohup.out byl, ale pak jsem ho smazal s tim, ze vse je OK. Malokdo si zalohuje vystupy z terminalu.
I když je nohup vystup přesměrovaný do /dev/null tak to vrací exit code, který se přečte v $?
-
Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.
-
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z
Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.
-
Proč by to nemělo jít poznat? Ať před nohup nebo ne, tak to vrací nějaký exit code:
Kdyz poustim nohup, tak je to proto, ze terminal-putty muzu zavrit a proces bezi dal. Pak se da vystup najit v nohup.out, pokud to nepresmeruji jinam (do /dev/null/)
-
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on JmenoArchivu.7z
Podle man lzma (viz CompMem; je to sice LZMA2, ale myslím, že to sedí i na 7z) je skutečná spotřeba paměti při kompresi asi desetinásobek velikosti slovníku -- určitě bylo na stroji, kde se to komprimovalo, 10GB RAM? Pokud ne, tak to po zkomprimování příslušně velké části vstupu (něco jako velikost RAMky děleno deseti) zhavarovalo na nedostatek paměti.
RAM je dostatek, LZMA pri tomto slovkiku vezme 10,7 GB RAM, LZMA2 o neco mene (rozdil je tusim jen okolo 100-200 MB), celkem cca 11x nasobek slovniku. K dispozici je 16 MB RAM nebo i 32 GB RAM tak se to vejde OK (pri 16 GB RAM to zabere 67%). K tomu se ale jeste pricte filelist, coz je okolo 1-2 GB na milion souboru. Az na par extremu se to vejde vzdy i do tech 16 GB.
-
Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.
Můžeš, ale tazatel na tebe evidentně sere a je přesvědčen o genialitě své kompresní metody, která podle něj sežere pouhých 10+GB RAM jen na ten slovník, což je úplně OK. ::) ;D
-
V tom případě by měla kontrola partition odhalit hnilobu v souboru
Neměla. Mohlo se to poškodit třeba vadnou RAM při kopírování. A kromě btrfs a ZFS nedělá žádný souborový systém kontrolu dat, která tu vadnou RAM většinou pomůže odhalit.
Konverze CRLF/LF?
O zaheslovane archivy se nejedna.
Jak souvisí potenciální poškození LF/CRLF s nějakým šifrováním o úroveň výš?
Jine soubory pokazene nemam.
Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.
Na chybu disku to nevypada, protoze jak prekopirovani souboru jinam, tak cteni a zipis na disk jde velice svizne bez problemu.
Disky, řadiče, procesory, ... s vadnou pamětí fungují úplně stejně jako ty v pořádku, jenom jednou za dlouho přehodí nějaký bit.
Presunuti jde bez jakychkoliv zaseku, ale pak pri pokusu otevrit/rozbalit/zkontrolova archiv to zahlasi, ze se nejedna o 7z archiv.
Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)
-
Mohu-li se zeptat, jestli ta úspora byla tak významná, že to stálo za to komprimovat s tak extrémním slovníkem, že mohla dojít paměť.
Uspora je jak kdy, podle typu dat a rozsahu podobnosti. U velkeho mnozstvi souboru je uspora 1024 MB slovnik oproti 64 MB slovkik 10-30 %, vyjimecne i 70% u specifickych dat. V naproste vetsine pripadu je vysledny archiv mensi minimalne (1-5 %), u obrazku pod 1% . Ale pamet by dojit jen tak nemela, i kdyz v par pripadech asi ano, pricina muze byt i jinde. Hlavni chybou je nedumyslna kontola dat.
Ad. Lol Phirae spamer. Tazatel na dotaz nesere, jen su nevsiml, ktere prispevky jsou nove.
-
Jine soubory pokazene nemam.
Jak to poznáš? Některé soubory mají uvnitř checksumy, ale u spousty na první pohled nějaký jeden bitflip uprostřed vůbec nepoznáš.
Jako že zkopíruješ funkční archiv a na kopii to řekne, že to není archiv? Porovnej SHA256 hashe těch souborů a pak to binárně diffni… (předtím se možná vyplatí zahodit pagecache, echo 3 > /proc/sys/vm/drop_caches)
Kdyz dam kontrolu vsech archivu, tak to hodi porad ty same chybne (pravdepodobne chybne od vytvoreni pred cca 2 roky). Kontrola archivu by mela chyby odhalit. Kdyz zkopiruju funkcni archiv, porad je funkcni a soubory se binarne nelisi.
Naopak archiv, ktery ma chybu, tak ma chybu i na jinych mistech (zalohy). Muselo dojit k chybe pred 2 lety, na jinem PC, pred presunem na externi disk.
Zaheslovani neni chyba, to proste 7z napise spatne heslo. Jinak pri rekurzivni kontrole 7z t slozka/ to bere jako archivy vsechny soubory, bez ohledu na priponu. Tedy kdyz se u archivu zmeni pripona na avi, stejne to pozna ze jde o archiv a testuje to jako archiv (mimo jine zmenou pripony archiv, byt zaheslovany se rovnez neda ukryt).
Naopak u souboru,ktere archivy nejsou se to snazi otevrit jako archiv a hodi to hlasku, chyba, soubor neni archiv, bezohledu na priponu.
Rekurzivni kontrolu umi jen novy 7z (z roku 2016) , starsi verze ne.