Sårbarheter i WinRar

Det är intressant att försöka mena på att det är en bra sak att 7zip inte klarade av att packa upp arkivet.

Mitt mål var att förvandla ett rar-arkiv till en användbar fil. Det kan omöjligt kännas som ett speciellt exotiskt användningsområde för en komprimeringsmjukvara.

Bara jag som använder sådana här program för att arkivera mappar, filer, etc, för att få lite mer städat på den (alltid för röriga) hårddisken? Arkivet går sedan ofta snabbare att hantera än en bunt separata filer och mappar, inte minst när man gör säkerhetskopia. Jag vet att inte fildatum blir helt koko för att man kopierar filer mellan olika enheter, filsystem, nätverk, etc.

WinRARs solida arkiv är kanske inte lika nödvändigt idag som förr, på diskett-tiden, när varje procent packning kunde spela roll (LZX var ett stort lyft när det kom till Amigan) (jaja, alla Unix-rävar, ni körde såklart tar och arc sedan länge), men solida arkiv med recovery data är inte så dumt om man ska bränna ut på optisk skiva tycker jag. Eller när man kopierar många arkiv från en hårddisk till en annan, pga exempelvis RAM-fel har jag (på en dator jag trodde var ok) varit med om att det vid några hundra GBs kopiering har blivit ett par fel eller två.

Kollar nu på Peazip, Maczip, Betterzip, etc, för att kanske bli lite mer bekväm med arkivprogram på MacOS; såväl 7zip som WinRAR är ju dock smidigare ännu under Windows (som jag ofta kör virtuellt).

Att RAR nu är/ska bli, integrerat i Windows kommer ju att öka användningen av RAR igen antar jag. Jag är egentligen förvånad att Microsoft tar detta steget, nu. Anses Zip för dåligt?

Finns PKZip, WinZip, WinRAR. Känns smidigare att öppna i WinZip än Windows, gammal vana kanske.
Eller så bara gillar jag dedikerade verktyg som gör en sak istället för allt i ett.

Men det är ju program man inte uppdaterar om det ej behövs, oftast när det kommer någon ny variant på zip eller rar.. vilket känns som inte speciellt ofta.

Det är libarchive som Microsoft ska använda sig av och det råkar ha stöd för bland annat RAR, men även exempelvis 7zip. Libarchive kan bara läsa, men inte skriva, rar-filer eftersom det är ett proprietärt format.

Så förhoppningsvis leder det till mer användning av öppna format.

Okay! Bra att du motfrågade för mitt svar nog mest en inlärd respons egentligen.

Jag är i den stora skalan en ny mac-användare så för att förtydliga så var det nog inte en avsaknad av mjukvara och eller alternativ till den...

Det handlade nog mer om att man var i tränad med vissa specifika namn som man sedan först inte visste hur man skulle ersätta dem.

Jag saknar ingen day to day mjukvara och vid numera casual gaming så har jag en dedikerad pc för det.

Det implementerar, är bara att w11 gömmer det ett steg extra.
Man får gå ner till "Visa fler alternativ" så har man funktionaliteten, men kan hålla med att det är lite dumt av M$ att lägga in en alternativ meny.

Asså, njae. Visst kan man väl klassa det som att det implementerar men är ju bara legacy menyn, inte direkt meningen att man ska använda den längre. Gamla borde tas bort helt så folk börjar använda den nya snabbare.

Är skeptisk till att det kommer förändra användningen nämnvärt, men vem vet.

Och jag tror ju snarare att de bara ville göra Windows inbyggda arkivstöd något mer användbart, detta då genom börjat använda opensourcebiblioteket libarchive som stöder en massa olika format.

Dvs, tror inte de bryr sig specifikt om zip eller rar eller något av de andra formaten är bättre, utan bara att Windows inbyggda stöd varit så begränsat att folk behöver tredjepartsverktyg även för att bara packa upp de vanligaste formaten.
Det konstiga är väl om något att de inte gjorde detta för länge sedan.

Tack för tips Noelia & Sweclockers!

För att om man använder det till att både komprimera och att packa upp så är Winrar i överlag den bättre lösningen, om man är ute efter hastighet och att göra det detta i .rar.
Om man endast packar upp filer så är 7zip snabbare.

ZIP är inte godkänd när man skickar känsligare data mot myndigheter mm. via mail - bara 7zip av en enda anledning (förutom inspekterbar open source-code) är att den också krypterar filkatalogen med ingående filer i arkivet vilket ZIP inte gör även om innehållet på filerna är krypterade med numera idag stark kryptoalgoritm som AES (och här fins det en lång lista av olika missar i ZIP-formatets historia i avseende kryptering i och därmed var möjliga att attackera och i många fall knäcka krypteringen och få ut innehållet i klartext).

om inte RAR-volymen växer markant i storlek när man har recovery-funktionen aktiv så har man förmodligen oberoende startpunkter utan beroende av blocken innan i komprimering.

gzip har reparations-verktyg med olika framgångar men den har också optionen '--rsyncable' vid komprimering vilket också gör att att den får blockuppdelning tillräcklig tydligt för att 'rsync' bara behöver plocka över partiella delar om gzip-fil har körts om med tex. en TAR:ad filträd med mindre förändringar i, vilket förmodligen underlättar en recovery ganska mycket.

99% av fallen med hämtade korrupta komprimerade filer från tex. FTP beror på att överföringen har gjort i ASCII-mode och inte i binary-mode. Hämtar man över filer med FTP eller SFTP så måste man noga ha kollat att det sker i binary-mode - och idag numera är det för det mesta default-satt i binary-mode men inte självklar förr i olika FTP-klienter.

---

Skall det kunna reparera för bit och byte-fel efter arkivets längd så innebär det att paritetsinformation måste läggas till och det tar plats, mycket mer än enstaka procent gentemot en oskyddad komprimerad fil.

Ofta använder man erase-kodning (dvs. man vet vilka och antal bitar som förväntas och som saknas i ett block och därmed betraktas som frågetecken) med blockkodare som reed-solomo.

Reed-solomo är en felrättningsalgoritm där den kan ersätta hela block med en eller flera fel i sig (inklusive att hela blocket saknas) till sin hela paritetsmängd och rätta slumpmässiga fel spridd över blockmängden den är kalkylerad på till halva sin paritetsmängd.

På typ tapestreamers liknande QIC80 så hade man 3 RS-block per 32 block - dvs. 29 block med data och 3 block med paritet, vilket gjorde att man kunde tolerera 3 korrupta eller oläsliga block per 32 block oavsett vilken block som hade fel i sig inklusive sin egna paritetsdata, mao. kunde man klara en bandsallat som efter uttrassling och utslätning (och eventuell klipp och klistra) med upp till 3 oläsabara block (eller saknad helt) och ändå få ut datat komplett och korrekt.

Var det spridda bit/bytefel över flera block än 3 block så var reparationskapacitet motsvarande 1.5 block i mängd data totalt över 32-blocks spannet och då inkluderar det att det finns fel även i paritetsblocken.

CD/DVD/BR-skivor har liknande metodik med RS-kodning eller annan BCH-kodning i olika ortogonala mönster samt spridning (interleaving) av data så att en sammanhängande 'repa' längs efter spåret spreds ut till spridda fel på betydligt större antal block som pariteten sedan enkelt kunde rätta.

Har använt winrar sedan barnsben, kommer alltid använda winrar

Jag kör med RAR bl a, men bara i terminaler då* .. inget GUIRAR för min del.
Köpte en licens för många herrans år sedan.

Edit:
* inkl Win, Mac, Lin