Kazí se archivy 7z?

[Honza1Ubuntu]

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.

[Reklama]

[Lol Phirae]

Ne, nekazí. Hnije ti disk nebo se to zkurvilo při kopírování.

[Pavouk106]

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.

[macík]

V tom případě by měla kontrola partition odhalit hnilobu v souboru

[v2kt0r]

Chyba disku, ransomware?

[Reklama]

[P_V]

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.

[BB]

Co 32bit vs 64bit, kdy se snažíš více než 2GB archiv otevřít pomocí 32bit 7zip?

[Honza1Ubuntu]

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.

[youarefired]

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.

[ByCzech]

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.

[trumbera]

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).

[Honza1Ubuntu]

 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)

[Honza1Ubuntu]

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.

[Honza1Ubuntu]

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]

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:

Kód: [Vybrat]

ERROR: Can't allocate required memory!