Všiml jsem si, že zobrazované procenta neodpovídají skutečnosti.
- komprese: čím více souborů, tím se dostane na méně procent. Při 37 000 souborech končí na 90% a archiv je hotový (ne, nemám aktivní přepínač -oi, který tohle dokáže, ale tam je na to důvod). Při kompresi jsem použil tyto přepínače: -ep1 -ma5 -k -df -v500m -rr10p -rv20p -cfg- -idn -ol -htb -qo+
- dekomprese: pokud archiv obsahuje záznam pro opravu (např. 10%) končí rozbalování u 90%. Jde chápat, OK (RAR zobrazuje procenta podle toho, kde se nachází v souboru, ne kolik rozbalil - pokud jde o nedělený archiv). U děleného archivu se zobrazuje přesně jak by mělo být.
ER se to nepodařilo reprodukovat , ale neměl v archivu odkazy. Myslí si ale, že špatná hodnota průběhu může být způsobena množstvím odkazů. Nezjišťovat zda se jedná o odkazy ušetří čas, takže přesný počet souborů není na začátku komprese známý.
Pokud je to skutečně závislé na množství odkazů, tak potom by ER řekl, že zkreslení je to přijatelné. Pravděpodobně to není nijak častý případ a oprava může způsobit zpomalení nebo zmatené skákání při průběhu komprimace pokud použijeme přímo velikost odkazu - teď jsem to možná špatně přeložil nebo pochopil...
Ano, WinRAR a RAR nebere ohled na velikost záznamu pro opravu a skutečně to zkresluje ukazatel průběhu. Oprava by znamenala snížení rychlosti rozbalování archivů typu RAR4, protože je třeba projít celý archiv a najít v něm záchranný záznam. Pro RAR5 archivy by mělo být možné použít rychlejší přístup a možná v budoucnu ER zkusí zjistit, jestli je možné to opravit aspoň pro RAR5 archivy.
Takhle to vypadá: https://uloz.to/file/PXVfpBzT9dJ7/procenta-png
Tento vzorek dat neobsahuje odkazy (mám ověřeno). Chová se to stejně bez -ol nebo s -ol.
Na obrázku jsou vidět příkazy, které jsem na to použil.
Můžete to zkusit i bez -idn?
Pokud je "gramps 2020" adresář, je možné že se jeho velikost změnila od začátku archivace?
"gramps 2020" je adresář, který obsahuje 68436 souborů o velikosti 1,6 GiB. Jedná se o zálohu, kterou jsem vytáhl pro test. Velikost se nemohla změnit, protože jsem to dočasně rozbalil.
Bez -idn je to samé, po dosažení 92% se uloží složky a je hotovo.
Zkoušel jsem i starší verze, jestli se nejedná o nedávnou chybu a chovají se stejně (i třeba 3.93)
Problém jsem byl schopen reprodukovat na adresáři se zhruba 42 000 soubory - výsledný archiv má velikost 63 MB a předal jsem to dál ER.
Mezitím se ER ozval, že zkoušel provést opravu RAR5 archivu, aby se do průběhu nepočítal záznam pro opravu, ale zjistil, že to bohužel bude také problematické. Znamenalo by to snížení výkonu při zpracování skupin archivů a dělených archivů. Bylo by potřeba otevřít každý archiv ve skupině a zjistit pozici záznamu pro opravu před začátkem rozbalování.
Takže pokud ER nepřijde jak to udělat, tak aby se nesnížil výkon, pravděpodobně nedojde k opravě.
Unix narozdíl od Windows vrací nenulové velikosti adresářů a RAR přidal tyto velikosti k celkové velikosti souborů - bude opraveno v další verzi, pravděpodobně 6.02
Díky
Ono záleží na použitém souborovém systému. Některý zobrazuje velikost složky a některý ne.
Na EXT4 je to bráno jako soubor - takže má velikost. Když mám složku "123", tak už nelze vytvořit soubor s názvem "123".