Kérdezz, jár erre pár guru. Hamarabb kapsz választ, ha precízen leírod mi a baj (oprendszer, sw verzió, hibaüzenetek, egyéb) - de kérünk, egy kérdést ne írj bele több topicba, kérdezés előtt keress vissza, hátha már volt a problémád.
Ja, és amennyiben warez windowsod lenne, ez nem az a hely ahol segítene bárki. És kodekpakkot, soha, sehova sem teszünk fel.
Jaja! Bizony jól tud jönni, különben nem lenne divatban, a játékok zsugorítása sem. A RIP-elés már eléggé kikopott egy műfaj lett mára. (pl: GTASA, 1CD-n.)
A jelenlegi médiafájljaink, sajnos nem egyszerű módon tömöríthetőek, de van rá példa. Itt van az új JXL-képformátum, az kb. 20%-al kissebbre tömöríti veszteségmentesen a meglévő JPG képeinket. Vagy Precomp, PackJPG, PAQ, stb.. MP3-ra is 6-7 csomagoló van. Veszteségmentesen.
Van, egy 300MB-os pakk, ami így hülyén van tömörítve:
22db ZIP-fájl, mindegyikben egy RAR-fájl van.
A RAR-ok, azok partXX.rar kiterjesztésűek. (ezek és a RAR-ok 15 002 xxx bájtosak. Kivéve az utolsót,)
A RAR-on belül egy pár apró fájl mellett, egy nagy ZIP-fájl van.
A ZIP-fájl, titkosított, jelszó is van hozzá.
A ZIP-en belül, asszem 5 millió bájtos *.ACE kötetek vannak.
A problémás ZIP állományból, amely a part.05-ös kötet hiányzik kb. 2500 bájtnyi adat. Igen, ez nem akkor mint a többi.
A tünet: Akár WinRAR 5.x vagy 7-ZIP-el esek neki, még a Sérült fájlok megtartásának erőltetésével is kiugrik, az 5.-ik kötet kb. 30%-nál, a többi fájlt már le se tojja. Ha, RAR-ként fixálom, ezt a kötetet, akkor nem 5 1xxx xxx bájtnyi, hanem majdnem az eredetivel megegyező méretűre kikorrigálható, még ha hibás is.
Hogyan kényszerítsük arra a RAR-t, hogy akár 0-ákkal is kitöltve, akár hibás adatokkal, az adott blokkokkat (4MB?), kicsomagolja teljesen a 300MB-os jelszavazott ZIP-fájlt? Az első 50-70 millió bájtnyi adat kivakarható belőle és ebből 11 *.ACE kötet is. Ha hibásan is volna egy része, de az utolsó bitig kibányászható valahogy az adat? Az ACE-archívumból kiszedett első nagy UHA-fájlból, ha teljes terjedelmében ki lenne szedve, vajon kiolvasható volna-e a fájlok listája, még ha hibás is volna annak kissebb/nagyobb szegmense? Feltéve, ha a teljes fájllista/CRC a fájl legvégén van. A fájlméreteket nézve volna még egy-két kissebb UHA archívum is, ezek biztosan hibátlanul dekkolnak, a 21-es és az utolsó 22-es ZIP/RAR-kötetben.
Az egyszerű javítási mód, a hibás 05-ös kötet cseréje volna. (Akár ZIP-ben, akár RAR-ban.) De, ha nincs?
Én csak azon csodálkozom, hogy 1-2 nagygépes céget miért nem döntöttek romba az egyszerű operátorok. Néha olyan jogkört kapnak, hogy yajj, aztán sablonokból írogatják be a parancsokat, egyet elír, nem figyel, hogy nem lépett bele a home könyvtárba és heló...
Emlékezetem szerint nagyméretű fájlok esetén kifejezetten észrevehető a különbség, mármint több, mint amit a diszkre írás okoz, de célzott tesztet nem csináltam az ügyben.
Hová mutat a link? Ez az EREDETI szerző által megosztott ZPAQ 7.15 archiváló XP-n is futtatható változata. De ha ennyire nem bízol benne, tessék ott van a forráskód is az oldalán, keresed meg és oszt fordítsd le, akár Linux-ra is vagy amire akarod. Még jó, hogy az aktuális WinRAR telepítő, nem RAR-ban tölthető le, a hivatalos oldalról. Remélem érthető.
A példa arra szolgált, hogy bizony lehet olyan helyzet, amikor 1bit elvesztése sem tolerálható, elég csak a floppy-a korszak rakoncátlankodó lemezeire gondolni. Ha, nincs se recovery record (ala WinRAR!), se egyéb adatunk a helyreállításhoz, akkor gond van. Manapság ritkán találkozunk ezzel, ahogy ki is fejtettétek itt többen. Szerencsénkre. Manapság, már nem divat annyira a tömörítés mint 20-30 éve, nincs akkora piaca neki, csak a gamer-társadalom egy része az, akik aktívan kihasználják a rést, gondolván a klasszikus újracsomagolásokra. Meg, az akadémikusok, programozók azok, akik még aktívan kutatják, a tömörítés világát. Eléggé meg torpantunk, ami azt illeti.
Aki kicsomagolná... Fogd a kedvenc HEX-szerkesztődet és keresd meg a .zpaq-fájlban, HEXA-ban a '0B'-t és írd át '0A'-ra. Oszt máris hibátlan lesz. Ha, a fájlnév, CRC és minden egyéb tárolva lenne az archívumban, akkor 161 bájtos volna a fájl. Amúgy, egy matematikai érdekesség ez a fájl, próbáld meg bármi mással a 10001 bájtnyi számsort, úgy 3-4 ezer bájt alá letömöríteni. Egy XP-s gép is 30> mp alatt végez a ki/becsomagolással. Az első kísérleti verzióknak kellett közel fél nap! Igaz, azon esetekben 1 millió bájtos fájl volt a kiindulási teszt alap.
Kár, hogy az egyéb adatok nem írhatóak le olyannyira könnyen ilyen formában, akár jól tömöríthetőek, akár véletlenszerűek. (Micsoda világ lenne, egy floppyn volna, csomó 4K-s film.)
Mármint nem feltétlenül a diszken keletkezik a bitflip (bár keletkezhet ott is, a mágneses réteg ellustulásától), de akárhol is keletkezik a folyamat során, non-ECC RAM esetén is a diszken köt ki. Így szerintem csak a megoldás szempontjából van jelentősége az okának, a hiba szempontjából közömbös, hogy honnan került a diszkre mert a lementése után biztonsági okokból úgysem lesz tovább használva csak akkor, ha bizonyítottan más alkatrész okozta.
"Mire az elromlott lemez szinkronizálását befejezte, arra pont el is hullott egy következő."
Hát ja, ld. még RAID5-halál címszó alatt!
Azóta már min. RAID6-ot használunk (aminek van is valami értelme, szemben a RAID5+hot spare 'megoldással'), másrészt nem véletlenül van beépítve a storage-cuccokba (tipikusan már a firmware-ekbe) a korábban említett disk scrubbing, ami időben ki tudja buktatni a problémákat.
Ad 1. Oszt' mijaf@szt csinyájjak linuxon egy vélhetően vindózos progival, amiről azt se tudni, hogy' müxik a gyakorlatban? (Tudom, tegyem föl a linuxos verziót.... Megnéztem, mi ez, nem kell.)
Ad 2. Megint mondom: tökmindegy, mi az algoritmus meg a progi, nyilván nem lehet hibátlanul kibontani egy összefirkált tömörítvényt!
Bocsi, de megint fogalmad sincs, miről beszélsz...
A kibontásos példa a biztosan hibátlan(ul letöltött, pl. md5sum vagy effélével ellenőrzött) fájlokra vonatkozik! (OK, ezt valóban nem emeltem ki...)
Amikor egy tömörítővel "ellenőrzöl" egy fájlt, az NEM olvassa végig a tartalmat, csak a metaadatokat nézi! Ha valahol egy becsomagolt fájlon belül van hiba, az ott nem fog kibukni!
Ebből a szempontból a tömörítés algoritmusa érdektelen, de maguk a tömörítő alkalmazások term. viselkedhetnek eltérően, akár ugyanannak az algoritmusnak más oprendceren futó progija is...
"Fileokról meg egyenbekről volt szó, a majom a dénest teljesen kreténmódon keverte ide."
Há'perszehogy, épp erre utaltam, ugyi...
Annyi öszefüggés lehet, hogy egycerü esetekben az említett infók lehettek egy konkrét diszken egy konkrét fájlban (ill. azon belül egy konkrét fizikai szektor[csoport]ban), ahol a jelenség valóban felléphetett.
Akkoriban több cikk volt ezekről, most csak ezeket találtam hirtelenjében. A Netflixesnél is leírták, hogy az adatbázis esett szét hardverhiba miatt keletkezett néma adatsérüléssel (utolsó mondatban a lényeg):
"On Monday, 8/11, our monitors flagged a database corruption event in our shipping system. Over the course of the day, we began experiencing similar problems in peripheral databases until our shipping system went down... We suspected hardware and moved the system to an isolated environment, gradually getting shipments moving again. Eventually the system was repaired and shipping returned to normal conditions. With some great forensic help from our vendors, root cause was identified as a key faulty hardware component. It definitively caused the problem yet reported no detectable errors."
Hozzám is hoztak be már olyan RAID5 tömböt amit visszaíró cache-el használtak és miután a 4 (nem ECC) RAM modulból a CPU-hoz közelebbi kettő megadta magát vagy a hőterheléstől vagy az elöregedéstől (mindkettőnek a paneljén felszakadt egy-egy chipnek egy-egy lába), így egy adatfelmásolás után szétesett a tömb a cache-ben keletkezett néma bithibák miatt, ami az ECC hiányában nem derültek ki azonnal. Szerencséjükre relatíve frissen keletkezett a probléma és csak kevés fájlt érintettek a hibák, így majdnem minden menthető volt.
Facebookosat elolvastam, de mi van benne? Valami frissítés közben elszálltak lemezek, az most vagy igaz vagy nem, vagy az volt vagy nem, ezért nem mutatta meg a fotókat, de később már igen. Szóval adatvesztés nem volt, a részleteibe meg nagyon nem mentek bele, nem nekünk való bulvár. Többit meg sem nyomom, nyilván Face másra és másképp való, ha éppen nincs ott a poszt vagy nem jelenik meg valakinek, azt sem tudni, hogy hiba-e vagy állapot és folyton dőlborul valami, eleve posztok csilliárdjai és képek tricsillirádjai kerülnek fel rá minden másodpercben. Másfajta kiszolgálásról szól az egész.
Netflixet is megnyomtam, első ránézésre semmi indokot nem írnak, hogy mi történt és miért, csak nem megy a DVDküldés, csókolom. Akkor itt mi is történt?
És akkor emlékezzünk meg egy 20 éves Hitachi tárolóról amit VÉGRE kiselejtezhettem, sorban döglöttek meg a lemezek, de még csak lassulás sem volt, már szinte napi 2 HDD-t cseréltem, mire a végére értünk. Hangos, zabál, embernyi magas rackben 600 gigás vincsikből ha minden igaz, akkor redundánsan kijött a 8 terabyte. Mire az elromlott lemez szinkronizálását befejezte, arra pont el is hullott egy következő. Oszt akkor hol a hiba? Annak aztán kihúzhattam a villanyt is, de ott voltak a kövület fapados MSAk, meg mindenféle jobbak, én azért láttam fényképen is viszonylag nagy EMC tárolókat, DASt. jó ég tudja miket szerteszéjjel. Nem kell mindenáron szoftverben és egyébben alulméretezett rendszert működtetni vagy ne érjen el egy olyan csoda FW hiba, mint pár éve a HPnál, aztán meg is vagyunk.
Már feltalálták a .zip vagy .7z tömörítést. Ami ott van mindenkinél.
De javaslok jobbat: egy .vhd file ntfs partícióját bitlockerrel titkosítsd le és másolj rá egy nagyobb txt filet. Oszd meg a jelszót. Na ebben egy-két 4kB részt nullázz ki, mintha a hdd szektora megdöglött volna vagy áramszünet/fagyás miatt átíródott volna.
Na ekkor (a 4kB részt kivéve) vissza tudjátok-e olvasni a txt filet?
Na, próbáljátok kicsomagolni, a 10001 bájtos "pi10k.txt" fájlt, az archívumból. (Nevezzétek át pi10k.txt...zpaq-ra, különben kiterjesztés nélküli fájlt kaptok.)
Teszteléshez: zpaq.exe x pi10k_damaged.zpaq -test
Kicsomagoláshoz: zpaq.exe x pi10k.txt_damaged.zpaq -to unpacked
Le volt már TÖLTVE a fájl, meg volt nyitva a WinRAR-ban és bele lesegettem a különféle állományokba, az "Alt-V" helyi parancs használatával, a WinRAR beépített fájlnézőkéjével. Az egész archívum hibátlan volt, a tesztelés folyamán, még mielőtt bármi egyebet csináltam volna vele. Már, túl voltam a 20.-ik fájlon és egyszer csak fogta magát és megkotlott az archívum! A sok ezer, ha csak nem 10-20k feletti számban megnyitott, kicsomagolt, becsomagolt, tesztelt archívum után ez volt az első alkalom, amivel ez történt. Igaz, *.xz állományokat elég ritkán töltök le, kerül a szemem elé, talán csak pár tucatot ha össze lehetne eddig számolni. Ha, 7z-ben lett volna, mint konténerbe lett volna rakva az adat és ugyanígy tömörítve, vajon megsérült volna-e?? Erre akartam utalni lentebb, valahol van is egy angol nyelvű cikk/okfejtés, ahol pont erről a sérülékenységről van szó, az újabb LZMA-család kapcsán.
