WinRAR 5.00 Packer

Verfasst vonNero24

Der Packer RAR bzw. Win­RAR gilt nach wie vor als einer der leis­tungs­fä­higs­ten sei­ner Art. Als kos­ten­pflich­ti­ge Share­ware hat er es jedoch seit gerau­mer Zeit schwer, auf dem Markt gegen die pri­mi­ti­ve inte­grier­te out-of-the-box ZIP-Lösung der Micro­soft-Betriebs­sys­te­me oder gar die völ­lig kos­ten­lo­sen und noch dazu Open-Source Lösun­gen wie 7‑Zip zu bestehen.

Aber Win­RAR ist nicht tot und so wur­de zum ers­ten Mal seit Juni 2012 wie­der eine neue Ver­si­on nach­ge­scho­ben, zum ers­ten Mal seit März 2011 gar ein Major-Release. Anders als bei der Vor­stel­lung der Ver­si­on 4.20 ist dies­mal in den Release-Notes kei­ne Rede von höhe­rer Geschwin­dig­keit. Aller­dings soll durch Ver­grö­ße­rung des Dic­tion­a­ry die Kom­pres­si­ons­ra­te im Stan­dard-Modus erhöht wor­den sein. Zudem kommt mit Ver­si­on 5.00 auch ein neu­es Datei­for­mat. Nach­teil: älte­re RAR-Ver­sio­nen kön­nen es nicht ent­pa­cken. Hier die voll­stän­di­ge Änderungsliste:

Ver­si­on 5.00

1. New RAR 5.0 archi­ving for­mat. You can use “RAR 5.0” opti­on in archi­ving dia­log or ‑ma com­mand line switch to crea­te RAR 5.0 archives.

Older soft­ware inclu­ding older Win­RAR ver­si­ons is not able to decom­press RAR 5.0 archi­ves, so if you plan to send an archi­ve to other peo­p­le, it is neces­sa­ry to take the com­pa­ti­bi­li­ty issue into con­side­ra­ti­on. You can sel­ect “RAR” ins­tead of “RAR5” opti­on in archi­ving dia­log to crea­te RAR 4.x archi­ves com­pa­ti­ble with pre­vious Win­RAR versions.

2. Chan­ges in RAR 5.0 com­pres­si­on algorithm:

a) maxi­mum com­pres­si­on dic­tion­a­ry size is increased up to 1 GB in 64 bit Win­RAR. 32 bit Win­RAR ver­si­on can use up to 256 MB dic­tion­a­ry when crea­ting an archi­ve. Both 32 bit and 64 bit
ver­si­ons can unpack archi­ves with any dic­tion­a­ry size, inclu­ding 1 GB;

b) default dic­tion­a­ry size for RAR 5.0 is 32 MB, typi­cal­ly resul­ting in hig­her com­pres­si­on ratio and lower speed than RAR 4.x 4 MB. You can use “Dic­tion­a­ry size” archi­ving dia­log opti­on or ‑md
switch to chan­ge this value;

c) ‑md switch syn­tax is modi­fied to sup­port lar­ger dic­tion­a­ry sizes. Append ‘k’, ‘m’ and ‘g’ modi­fiers to spe­ci­fy the size in kilo‑, mega- and giga­bytes, like ‑md64m for 64 MB dic­tion­a­ry. If modi­fiers are not pre­sent, mega­bytes are assu­med, so ‑md64m is equal to ‑md64;

d) RAR 5.0 for­mat includes Intel IA-32 exe­cu­ta­ble and del­ta com­pres­si­on algo­rith­ms, but RAR 4.x text, audio, true color and Ita­ni­um algo­rith­ms are not sup­port­ed. The­se excluded algo­rith­ms are not effi­ci­ent for modern data types and hard­ware configurations;

e) RAR 5.0 decom­pres­si­on can uti­li­ze seve­ral CPU cores. Though not to same ext­ent as in com­pres­si­on algo­rithm, it impro­ves the decom­pres­si­on speed on lar­ge files with poor­ly com­pres­si­ble data or when using BLAKE2 checksums.

3. Chan­ges in RAR 5.0 archi­ve format:

a) file times are stored as Coor­di­na­ted Uni­ver­sal Time (UTC) ins­tead of for­mer local time, making file exch­an­ge among seve­ral time zones more straightforward;

b) file names and archi­ve comm­ents use UTF‑8 encoding.

4. RAR 5.0 reco­very record is based on Reed-Solo­mon error cor­rec­tion codes. If reco­very record size is lar­ge enough, 5% and more, the new error cor­rec­tion sche­me pro­vi­des much hig­her resis­tance to mul­ti­ple dama­ges com­pa­ring to RAR 4.x reco­very record. Smal­ler record, such as 1 — 2%, or less ran­dom dama­ge type would result in less dif­fe­rence bet­ween 4.x and 5.0. For sin­gle con­ti­nuous dama­ge 4.x and 5.0 effi­ci­en­cy is about the same.

Addi­tio­nal­ly to usu­al data era­su­res, the new reco­very record is able to detect dele­ti­ons and inser­ti­ons of much lar­ger size than in pre­vious RAR ver­si­ons. Maxi­mum inser­ti­on size is seve­ral mega­bytes. Maxi­mum dele­ti­on size depends on the dama­ge type and in some cases can be as lar­ge as the reco­very record size.

Still, the best reco­very per­for­mance and effi­ci­en­cy is achie­ved if no dele­ti­ons and inser­ti­ons are pre­sent, so all data inclu­ding dama­ged sec­tors pre­ser­ve their ori­gi­nal posi­ti­ons. Thus, if you use some spe­cial soft­ware to copy an archi­ve from dama­ged media, it is bet­ter to choo­se the mode, when dama­ged sec­tors are fil­led by zeroes or any other data ins­tead of cut­ting them out com­ple­te­ly from resul­ting file.

RAR 5.0 reco­very record is more resistant to dama­ge of reco­very record its­elf and can uti­li­ze a par­ti­al­ly cor­rupt reco­very record data. Note, though, that “Repair” com­mand does not fix bro­ken blocks in reco­very record. Only file data are cor­rec­ted. After suc­cessful archi­ve repair, you may need to crea­te a new reco­very record for saved files.

New reco­very record is not based on 512 byte sec­tors any­mo­re and incor­po­ra­tes more com­pli­ca­ted data struc­tures. So it is impos­si­ble to spe­ci­fy its size in sec­tors. For RAR 5.0 archi­ves the para­me­ter of ‑rr[N] switch and rr[N] com­mand is always trea­ted as a per­cent of archi­ve size regard­less of pre­sence of % cha­rac­ter. Typi­cal­ly N% reco­very record can repair up to N% of con­ti­nuous­ly dama­ged data and increa­ses the archi­ve size by only slight­ly more than N%. Abili­ty to fix mul­ti­ple dama­ges is pro­por­tio­nal to N.

We used “Screa­ming Fast Galo­is Field Arith­me­tic Using Intel SIMD Ins­truc­tions” paper by James S. Plank, Kevin M. Green­an and Ethan L. Mil­ler to impro­ve Reed-Solo­mon coding per­for­mance. Also we are gra­teful to Artem Dro­ba­nov and Bulat Zigans­hin for samples and ide­as allo­wed to make Reed-Solo­mon coding
more efficient.

5. “Test” com­mand veri­fies vali­di­ty of RAR 5.0 reco­very record. Reco­very record is tes­ted after pro­ces­sing all archi­ved files.
If cor­rupt archi­ve con­ta­ins the reco­very record, it might be pos­si­ble to repair it even if reco­very record vali­di­ty test is failed.
“Repair” com­mand attempts to uti­li­ze even a par­ti­al­ly dama­ged reco­very record. So tre­at the nega­ti­ve reco­very record test result as a reason to re-crea­te the archi­ve if ori­gi­nal files are still available, but not as a reason to avo­id “Repair” command.

6. Chan­ges in RAR 5.0 encryp­ti­on algorithm:

a) encryp­ti­on algo­rithm is chan­ged from AES-128 to AES-256 in CBC mode. Key deri­va­ti­on func­tion is based on PBKDF2 using HMAC-SHA256;

b) spe­cial pass­word veri­fi­ca­ti­on value allows to detect most of wrong pass­words wit­hout neces­si­ty to unpack the enti­re file;

c) if archi­ve hea­ders are not encrypt­ed (“Encrypt file names” opti­on is off), file checks­ums for encrypt­ed RAR 5.0 files are modi­fied using a spe­cial pass­word depen­dent algo­rithm, to make impos­si­ble gues­sing file con­tents based on checks­ums. Do not expect such encrypt­ed file checks­ums to match usu­al CRC32 and BLAKE2 values.

7. RAR 5.0 archi­ves allow to uti­li­ze 256 bit length BLAKE2sp hash ( https://blake2.net ) ins­tead of 32 bit CRC32 as a file checks­um. Enable “Use BLAKE2 file checks­um” opti­on in “Opti­ons” page of archi­ving dia­log or spe­ci­fy ‑htb com­mand line switch to use BLAKE2 checksums.

While pro­du­cing slight­ly lar­ger archi­ves, BLAKE2 can be used for file con­tents iden­ti­fi­ca­ti­on. If two files have the same BLAKE2 value, it prac­ti­cal­ly gua­ran­tees that file con­tents is the same. BLAKE2 error detec­tion pro­per­ty is also stron­ger than in much shorter CRC32.

8. Fea­tures removed:

a) authen­ti­ci­ty veri­fi­ca­ti­on fea­ture did not pro­vi­de the requi­red level of relia­bi­li­ty and was removed;

b) switch ‑en (do not add “end of archi­ve” block) is not sup­port­ed by RAR 5.0 archi­ves, which always have the end of archi­ve block. This block helps Win­RAR to safe­ly skip exter­nal data like digi­tal signa­tures appen­ded to archive;

c) old style exten­si­on based arcname.rNN volu­me names are not sup­port­ed by RAR 5.0 archi­ves, which use only arcname.partN.rar volu­me names;

d) file comm­ents are not sup­port­ed any­mo­re both in RAR 4.x and RAR 5.0 archi­ves. Con­so­le RAR ‘cf’ com­mand is remo­ved. It does not affect the archi­ve com­ment sup­port, which is pre­sent in both ver­si­ons of archi­ve for­mat and is not plan­ned for removal.

9. “Set pass­word” com­mand and “Dic­tion­a­ry size” opti­on are moved to “Gene­ral” page of archi­ving dialog.

10. You can use “Save sym­bo­lic links as links” opti­on on “Advan­ced” page of archi­ving dia­log to save and res­to­re NTFS sym­bo­lic links and repar­se points as links, so their con­tents is not archi­ved. Com­mand line equi­va­lent of this opti­on is ‑ol switch.

Simi­lar opti­on for NTFS hard links is “Save hard links as links”. Its com­mand line equi­va­lent is ‑oh switch.

Both opti­ons are available only for RAR 5.0 archi­ve format.

11. Added extra­c­tion only sup­port for XZ archi­ve format.

12. Chan­ges in reco­very volu­me pro­ces­sing in RAR 5.0 archi­ve format:

a) maxi­mum num­ber of RAR+REV volu­mes in RAR 5.0 for­mat is 65535 ins­tead of 255;

b) reco­very volu­me ope­ra­ti­ons are fas­ter than in RAR 4.x;

c) addi­tio­nal­ly to reco­very data, RAR 5.0 REV files also store ser­vice infor­ma­ti­on such as checks­ums of pro­tec­ted RAR files. So they are slight­ly lar­ger than RAR volu­mes which they pro­tect. If you plan to copy indi­vi­du­al RAR and REV files to some remo­va­ble media, you need to take it into account and spe­ci­fy RAR volu­me size by a few kilo­bytes smal­ler than media size.

13. Maxi­mum path length for files in RAR and ZIP archi­ves is increased up to 2048 characters.

14. Com­mand line RAR returns the exit code 11 if it can detect that user ente­red a wrong pass­word. This code can be retur­ned only for RAR 5.0 archi­ves. It is impos­si­ble to distin­gu­ish a wrong pass­word and data dama­ge for RAR 4.x archives.

15. ‘v’ and ‘l’ com­mands dis­play archi­ved file names in the end of line, not in that begin­ning as befo­re. Also some fields pre­vious­ly available in ‘l’ and ‘v’ out­put are now shown only by ‘lt’ and ‘vt’.

‘vt’ and ‘lt’ com­mands pro­vi­de the detail­ed mul­ti­li­ne infor­ma­ti­on for every archi­ved file.

‘vta’ and ‘lta’ also include ser­vice hea­ders into list.

16. Now the default char­set for file­lists in com­mands like ‘rar a arc­na­me @filelist’ is ANSI for both Win­RAR and con­so­le RAR. In pre­vious ver­si­ons it was ANSI for Win­RAR and OEM for con­so­le RAR. You can use ‑scl switch to over­ri­de this default.

17. Inter­nal Win­RAR view­er can detect and dis­play files in UTF‑8 and UTF-16 litt­le endi­an encodings.

18. UTF-16 litt­le endi­an enco­ding is used in RAR and Win­RAR log file rar.log, so Uni­code file names are stored in the log cor­rect­ly. Win­RAR auto­ma­ti­cal­ly trun­ca­tes the old rar.log file in non-Uni­code for­mat to avo­id mixing dif­fe­rent enco­ding in the same log file. In case of con­so­le RAR you need to dele­te the old rar.log manu­al­ly, other­wi­de RAR will append UTF-16 mes­sa­ges to exis­ting rar.log.

You can use ‑scg switch to chan­ge the default log file enco­ding, such as ‑scag for ANSI encoding.

19. Com­mand line ‘r’ (repair) com­mand can include an optio­nal dest­path\ para­me­ter defi­ning the desti­na­ti­on fol­der for repai­red archive:

rar r archive.rar destpath\

Down­load:

Links zum Thema: