Řešení 1:
tar (a cpio a afio a pax a podobné programy) jsou streamově orientované formáty – jsou určeny k přímému streamování na pásku nebo k přenosu do jiného procesu. i když by teoreticky bylo možné přidat index na konec souboru/streamu, nevím o žádné verzi, která by to dělala (i když by to bylo užitečné vylepšení)
nepomůže to s vašimi stávajícími archivy tar nebo cpio, ale existuje další nástroj, dar („archiv disku“), který vytváří archivní soubory obsahující takový index a může vám poskytnout rychlý přímý přístup k jednotlivým souborům v archivu. .
pokud dar není součástí vašeho unix/linux-dist, můžete jej najít na:
http://dar.linux.free.fr/
Řešení 2:
Pro takové archivy můžete použít SquashFS. Je to
- navrženo pro přístup pomocí ovladače pojistek (ačkoli existuje tradiční rozhraní)
- komprimovaný (čím větší velikost bloku, tím efektivnější)
- zahrnuto v jádře Linuxu
- ukládá UID/GID a čas vytvoření
- ohled na endianess, tudíž docela přenosný
Jedinou nevýhodou, o které vím, je, že je pouze pro čtení.
http://squashfs.sourceforge.net/http://www.tldp.org/HOWTO/SquashFS-HOWTO/whatis.html
Řešení 3:
I když neukládá index, star je údajně rychlejší než tar . Navíc podporuje delší názvy souborů a má lepší podporu pro atributy souborů.
Jak jistě víte, dekomprimace souboru nějakou dobu trvá a pravděpodobně by byla faktorem v rychlosti extrakce, i kdyby tam byl index.
Upravit: Můžete se také podívat na xar . Má hlavičku XML, která obsahuje informace o souborech v archivu.
Z odkazované stránky:
Hlavička XML Xar umožňuje obsahovat libovolná metadata o souborech obsažených v archivu. Kromě standardních unixových metadat souborů, jako je velikost souboru a jeho úpravy a doby vytvoření, může xar ukládat informace, jako jsou bity souborů ext2fs a hfs, unixové příznaky, odkazy na rozšířené atributy, informace Mac OS X Finder, Mac OS X zdrojových větví a hash dat souboru.
Řešení 4:
Thorbjørn Ravn Anderser má pravdu. GNU tar standardně vytváří "hledatelné" archivy. Ale nepoužije tyto informace při čtení těchto archivů, pokud není zadána volba -n. Pomocí volby -n jsem právě extrahoval 7GB soubor z 300GB archivu v čase potřebném k přečtení/zápisu 7GB. Bez -n to trvalo déle než hodinu a nepřineslo žádný výsledek.
Nejsem si jistý, jak to ovlivňuje komprese. Můj archiv nebyl zkomprimován. Komprimované archivy nejsou "vyhledatelné", protože aktuální (1.26) GNU tar přenáší kompresi na externí program.
Řešení 5:
Jediný formát archivu, o kterém vím, že ukládá index, je ZIP, protože poškozené indexy jsem musel rekonstruovat více než jednou.