Dobrý den,
chci se zeptat, zda se nejedná o chybu v RARu.
Pokud vytvářím archiv bez solid funkce, RAR ukladá soubory, které jsou větší po kompresi bez komprese (-m0). Tohle se děje jenom u prvního partu.
Soubory, které přesahují party, tak tam se to jde chápat, že to neprovede. Např. následný soubor, který je celý v partu 2 již není uložen bez komprese a je větší, jak původní soubor.
Výpis vzorku: https://workupload.com/file/3jL8HQkQfnM
Je to záměr nebo chyba?
Zeptal jsem se ER a dám vědět až odpoví. Díky.
můžete poslat použitý příkaz?
vrací
RAR 6.10 Copyright (c) 1993-2022 Alexander Roshal 24 Jan 2022
Archive: 1.part1.rar
Details: RAR 5, volume 1, recovery record, lock
Attributes Size Packed Ratio Date Time Checksum Name
----------- --------- -------- ----- ---------- ----- -------- ----
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 1).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 10).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 11).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 2).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 3).deb
-rwxrwx--- 90845912 3543969 --> 2022-02-08 13:01 CCB930AC 1/google-chrome-stable_current_amd64 (copy 4).deb
----------- --------- -------- ----- ---------- ----- -------- ----
545075472 457773529 83% &nb sp; 6
Archive: 1.part2.rar
Details: RAR 5, volume 2, recovery record, lock
Attributes Size Packed Ratio Date Time Checksum Name
----------- --------- -------- ----- ---------- ----- -------- ----
-rwxrwx--- 90845912 87301943 <-- 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 4).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 5).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 6).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 7).deb
-rwxrwx--- 90845912 90845912 100% 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 8).deb
-rwxrwx--- 90845912 7087941 --> 2022-02-08 13:01 C25A2172 1/google-chrome-stable_current_amd64 (copy 9).deb
----------- --------- -------- ----- ---------- ----- -------- ----
454229560 457773532 100% ; &n bsp; 5
Archive: 1.part3.rar
Details: RAR 5, volume 3, recovery record, lock
Attributes Size Packed Ratio Date Time Checksum Name
----------- --------- -------- ----- ---------- ----- -------- ----
-rwxrwx--- 90845912 83757971 <-- 2022-02-08 13:01 122A6EB3 1/google-chrome-stable_current_amd64 (copy 9).deb
----------- --------- -------- ----- ---------- ----- -------- ----
& nbsp; 0 83757971 0% & nbsp; &nbs p; 0
999305032 999305032 100% ; &n bsp; 11
Přepínač -m0 tam není. To RAR vkládá, pokud je komprimovaný soubor větší jak původní. To se děje jenom u partu 1. U dalších to nefunguje.
Funguje to takhle od verze 5.30.
Ve zkratce odpověď zní, že je to tak navržené a má to tak fungovat. Dlouhá odpověď anglicky přímo od ER:
Indeed, RAR can store a file with zero compression if file has grown in size after archiving. But it happens only for non-solid non-volume archives, because it would be more complicated to implement it for solid archives and volumes. I've checked RAR 5.00 and it doesn't switch to store mode just like RAR 6.10 with switches provided by user.
Now I do not remember exactly what difficulties are associated with implementing this for volumes. I suppose, it might be possible to implement it for volumes as well. But I seriously doubt it really worths the effort even if technically possible.
RAR5 compression overhead is a quite small for non-compressible files. It is less than 0.2% in listing provided by user. Reading again a large file, which doesn't fit into disk cache, can be a quite time consuming. It is questionable if 0.2% gain is worth reading a file again and waiting.
I implemented storing incompressible files long before RAR5 format. Older RAR formats had noticeably larger overhead in this case and this feature was reasonably useful. RAR5 format inherits this code from older versions. But if I had implemented it from scratch, I am not sure I would care about mere 0.2%.
Initially I thought he used -m0 switch. In this case, of course, RAR must respect the switch and store files without compression as requested by user. But repeated processing in store mode for incompressible files without -m0 switch was not guaranteed in older versions too and decision is made by RAR based on the archive type and other factors.
Možná do budoucnosti: "rozbalení" takového souboru je mnohem rychlejší.
Tato funkce by mohla být dostupná jenom pro non-solid multivolume archivy bez šifrování. Jenom by neplatilo pro soubory, které přesahují jednotlivé party.
poslal jsem dal ER
ER to někdy v budoucnu zváží i přestože dekomprese RAR5 je celkem rychlá. Aktuálně naměřil 350 MB/s pro špatně komprimovatelná data na Ryzenu 3950X. Této rychlosti dosáhne už pro osm vláken, takže vysokorychlostí mnohojádrové procesory nejsou potřeba.
Díky za nápad.