Hlavní navigace

Organizujeme data (2) - další tipy

8. 10. 2002
Doba čtení: 9 minut

Sdílet

I v dnešním dílu budeme pokračovat částečně v nelinuxovém duchu a podělím se s vámi o své zkušenosti při práci s vlastními daty. Dnes bude řeč o rejstřících CD, odkazech, rekonstrukci starých dokumentů, přijdou na řadu úvahy o aktuálním adresáři, jménech souborů, testovacích adresářích a používání relací.

CD a jejich rejstříky

Nejběznějším médiem pro úschovu dat jsou CD. Protože vytažení CD z pořadače, vložení do mechaniky a načtení dat znamená zhuba minutu času (nemáme-li na to robota), je praktické mít vždy po ruce alespoň rejstříky od všech CD. Ty připravuji ještě před vypálením a kopii si ponechávám na disku (viz též Drobnosti ze shellového zápisníku III.). Takový rejstřík vyrobíme snadno, postavíme-li se do adresáře s daty pro vypálení:

# unifikace práv pouze ke čtení
#chown -R root:root .
chmod -R u+rX,g+rX,o+rX .
chmod -R u-stw,g-sw,o-w .
# vyrobíme seznam
LANGUAGE=C LANG=C ls -AlR --full-time |\
 sed s/\\.000000000// >../ls-lR
# přesuneme jej do vypalovaného adresáře
chmod u-w,g-w,o-w ../ls-lR
chmod +w .
mv ../ls-lR .
chmod -w .

(Přesné znění příkazu ls závisí na verzi fileutils, tato platí s verzí 4.1.5.)

Protože na CD většinou ukládám archivy, je užitečné mít po ruce i kompletní výpisy všech archivů:

# ve výrazu s/\\240/ /g je znak NBSP (160/0xa0)
find '(' -name '*.tar.gz' -or -name '*.tar.bz2' ')'\
 -exec sh -c "\
  echo {}':' ;\
  if [ \"\$(basename \"{}\" .tar.gz)\" =\
     \"\$(basename \"{}\")\" ] ;\
  then tar -I -t -v -f \"{}\" ;\
  else tar -z -t -v -f \"{}\" ;\
  fi" ';' |\
 sed 's/\\240/ /g' >../ls-archives
chmod u-w,g-w,o-w ../ls-archives
chmod +w .
mv ../ls-archives .
chmod -w .

(Prezentovaná verze nevypisuje archivy *.tgz nebo *.zip, ale verzi lze snadno vytvořit. Kvůli unifikaci formátu výpisu bychom u zip archivů museli provést dekompresi a převod do formátu tar. Parametr pro bzip2 kompresi u programu tar se liší podle verze UNIXu/Linuxu – -I, -y, nebo-j.)

Odkazy

Odkazy jsou UNIXovou specialitou (pomineme-li tzv. zástupce v některých jiných systémech). O jejich používání při organizování dat se proto většina učebnic nezmiňuje.

Pevné odkazy

Pevné odkazy nejsou vlastně ničím jiným než vícenásobným názvem pro tentýž fyzický soubor. Že na soubor existuje ještě další odkaz, poznáme např. podle výpisu ls -l (druhé pole zleva).

Z hlediska práce s nimi pak rozeznáváme aplikace, které při zápisu do souboru s odkazem provedou fyzický zápis do původního souboru (tzv. jednoduchý zápis, kdy se pod všemi původními jmény souboru objeví nový obsah), nebo provedou „odtržení“(často pomocí tzv. bezpečného zápisu, kdy dojde k oddělení zapsaného souboru od jeho původního obsahu a stává se z něj nový samostatný objekt). Až na výjimky (např. Emacs) toto chování nelze nastavit a ani v návodu to není deklarováno, takže nezbývá, než provést experiment.

Hlavní výhodou pevných odkazů je úspora místa u identických souborů. Další výhodou je přenositelnost – pokud operační systém nepodporuje pevné odkazy, vidí je jako úplně obyčejné soubory. Je tedy vhodný např. pro vypalování CD (cdrecord si s pevnými odkazy poradí, a pokud žádný z nich nemíří mimo vypalovaná data, pak dokonce i korektně). Jednoduchá je i archivace – stačí záloha jediné instance souboru.

Proti tomu stojí nevýhody – problémy při kopírování, rozpadnutí vazby při archivaci do několika souborů a nakonec značná náročnost vyhledání dalších jmen příslušného souboru (musíme vypsat celý disk a porovnat hodnoty i-uzlů).

Symbolické odkazy

Protože symbolické odkazy neobsahují nic jiného než jméno odkazovaného souboru, je třeba dávat velký pozor na archivaci. Snadno by se mohlo stát, že nám zbyde jen nikam nemířící odkaz.

Při práci rozlišujeme dva typy odkazů – absolutní a relativní. Na to musíme při práci pamatovat – byť pošle Jarda Frantovi kompletní data, připraví mu nejednu nepříjemnou chvilku, když všechny odkazy budou ukazovat na neexistující objekty/home/jar­da/obrázky/co­si. Proto až na výjimky používám při práci pouze relativní odkazy, tedy ../obrázky/cosi. Taková data jsou bez problémů přenositelná do nového prostředí.

Výhody symbolických odkazů? Jednoznačně dávají najevo, kam ukazují a odkud data bereme. A nevýhody? Chceme-li prostředí plné symbolických odkazů obnovit na jiném počítači, znamená to archivaci a rozbalení všech cílů odkazů – tedy často mnoha adresářů.

Co archivovat?

Není příliš užitečné schovávat přechodné a dočasné soubory, které snadno vygenerujeme (víme-li, jak – návod na jejich generování je tedy mimořádně užitečnou informací). Pouze pokud se z principu věci stane, že budeme často potřebovat data ve stavu, v jakém byla v určitém okamžiku v minulosti, je na místě vyrobit kompletnější zálohu.

Není však k ničemu dlouhodobé zálohování dat, jejichž pořízení sice bylo nákladné, ale sloužila pouze k jednorázovému účelu a příště je nepůjde použít ani jinak zužitkovat.

Rekonstrukce a aktualizace

Pokud si neukádáme generovaná data, jsou dvě principiální možnosti, jak je získat. Rekonstrukce je proces, při kterém se snažíme získat stejný výstup, jaký měla data původně. Při aktualizaci generujeme nový výstup ze stejných základních vstupních dat, ale můžeme při tom použít novějších vkládaných dat. Takový výstup již nemusí odpovídat původní předloze.

Ukážu to na příkladu: Před několika lety jste napsali zprávu, třeba ve firemním stylu v LaTEXu. Nyní ji budete opět potřebovat. Rekonstrukce znamená, že dostanete původní podobu této zprávy včetně grafické úpravy. Regenerace pak znamená, že ve zprávě bude sice původní text, ale bude na novém hlavičkovém papíře s novými telefonními čísly a s novým logem.

Vidíme, že oba postupy mají svůj smysl.

Nyní vysvětlím, jak se s tímto problémem při práci vypořádávám.

Pro rekonstrukci musíme použít všechna data shodná (nebo alespoň kompatibilní) s původními daty, zatímco pro regeneraci použijeme jen základní vstupní soubory a ostatní data použijeme z aktuálních zdrojů.

Mějme data pátého dílu fiktivní edice o psech, sázené v TEXu.

PN0009Psi5_ratlíci-+-ratlici.tex
                   |-edice.tex
                   |-makra.tex
                   |-loga/
                   +-obrazky/

Soubory edice a maker se však nemění často. Při reedici za rok nebudu jasně vidět, zda jsem provedl jejich změnu, nebo ne.

Mohl jsem tedy použít symbolické odkazy na jejich poslední verzi:

edice.tex -gt; ../PN0003Psi2_jezevčíci/edice.tex
makra.tex -gt; ../PN0001Kočky/makra.tex

Výhoda? Pouhou aktualizací odkazů provedu aktualizaci dokumentu. Nevýhoda – při rekonstrukci budu rozarchivovávat tři adresáře. Mohl jsem však mít také samostatný (tj. jediný) archiv maker:

edice.tex -gt; ../PNmakra/edice_psi_v2.tex
makra.tex -gt; ../PNmakra/makra_v5.tex

Stejně tak jsem se mohl odkazů zcela zbavit a v TEXu napsat:

\input ../PNmakra/edice_psi_v2
\input ../PNmakra/makra_v5

Povšimněte si čísel verzí v názvech. Jsou velmi důležitá, protože makra_v6 sice dávají lepší výsledky, ale také jinak vypadající výstup.

Aktualizace by pak proběhla přepsáním názvů či odkazů na poslední dostupné verze.

Třetí cesta vede přes trvalé zálohování adresáře s makry při každé změně (pomocí CVS nebo obyčejné archivace). Čísla verzí bychom pak nepoužili. Při novém generování by se automaticky provedla aktualizace. Pokud bychom chtěli provést rekonstrukci, na chvíli bychom odložili současný obsah adresáře a v archivech bychom našli zálohu k příslušnému datu.

Tento postup však má jednu nevýhodu – pokud bychom při přípravě 6. dílu našli drobnou chybu v makrech a 5. díl by ještě nebyl zcela dokončen, mohlo by se stát, že při opravě dojde k nežádoucím změnám v již dokončené části 5. dílu. Proto se tomuto postupu vyhýbám.

Problém rekonstrukce ukážu na příkladu z praxe: V roce 1997 jsem připravil sazbu knihy. Pro dotisk po čtyřech letech bylo třeba znovu vytisknou jednu poškozenou dvoustranu. Tiskový postscriptový soubor by k tomu byl velmi užitečný, ale nezálohoval jsem jej – je velký, nejde editovat a obyčejně není po vytištění k ničemu. Sáhl jsem tedy do záloh dat a tiskový soubor znovu vygeneroval. Sazba ovšem nesouhlasila! Po dlouhém pátrání jsem zjistil, že od té doby jsem udělal v pomocných makrech několik oprav, aniž bych zazálohoval původní stav. Přestože nová sazba byla díky opravě v makrech graficky lepší, byl původní stav nerekonstruova­telný.

Proto pozor – uchovávejte si všechny starší vkládané styly, písma, vzory dělení, předlohy součástek apod., a to včetně záznamu o tom, kdy jste provedli aktualizaci. Po letech se to může hodit.

Místo pro zápis a aktuální adresář

Programy z příkazové řádky již dlouhé desítky let používají konvencí aktuálního adresáře. Jeho význam jistě nemusím čtenářů Rootu vysvětlovat. Aplikace spouštěné z příkazového řádku tedy nemají problém s výběrem vhodného adresáře pro zápis dat a implicitně nabízejí aktuální adresář.

Je s podivem, že tento geniální vynález neadoptoval žádný grafický systém. Přitom si velmi dobře dovedu představit v KDE nebo GNOME panelu CD aplet, který změní aktuální adresář pro všechny spouštěné aplikace.

Grafické systémy tedy v tomto bodě organizaci dat spíš komplikují. Nejhorší aplikace lze označit za „inkontinentní“ (neboť „dělají pod sebe“). Toto řešení je naštěstí v UNIXu vzácné (do adresáře/usr/bin běžný uživatel nemůže zapsat, a tak jej takový program zdravě naštve, zvlášť pokud se musí doklikat do domovského adresáře před každým zápisem). Ideální situace je taková, kdy aplikace nabízí buď standardní adresář (domovský v UNIXu a dokumentový v jednouživatel­ských systémech), nebo poslední použitý adresář (který si voliteně pamatuje i při příštím startu).

Ne každá aplikace se však chová inteligentně, a tak občas používám náhradní řešení – domovský adresář obsahuje pouze další podadresáře, ale žádné soubory (nezačínající tečkou). Při vhodném nastavení tak můžeme pro rozpracovanou zakázku nouzově používat přímo domovský adresář a pak jediným příkazem všechna data přesunout tam, kam patří. Je to rychlejší, než se tam pokaždé doklikávat.

Dobré jméno – základ úspěchu

To platí nejen pro názvy firem, ale i souborů. Většina UNIXů nabízí délku jména alespoň 32 znaků. Vypisovat jej většinou nemusíme (programy mívají buď GUI, nebo alespoň automatickou kompletaci názvu po stisknutí tabulátoru). Nejsme tedy výrazně omezeni.

Chceme-li se vyhnout problémům v některých programech, je vhodné namísto mezer použít podtržítko, u některých programů se musíme vyhnout i znakům mimo ASCII tabulku (tedy češtině).

Adresář na hlouposti a zkoušky

Každý máme na svém počítači takový adresář (často i více). Problém nastává tehdy, když je tento adresář hlavním místem pro ukládání dat.

Tyto adresáře by měly být určeny výhradně na přechodnou dobu. Abychom jejich velikost udrželi na rozumné velikosti, stanovíme si svá pravidla. Uvedu příklad (každý by si měl vytvořit taková pravidla, která mu vyhovují):

Adresář ~/tmp: Pracovní data zakázek tam odkládám po jejich uzavření do stejnojmenných adresářů. Přímo v adresáři ukládám staré protokoly o mailech a výsledky různých převodů, které se sice mohou hodit, ale jejich vytvoření bylo natolik jednoduché, že je nemá smysl archivovat. Mažu je po půlroce nebo při nedostatku místa.

Adresář ~/tmp/tmp: Dočasná data. Místo, kam ukládám různé tiskové soubory, pracovní soubory pro převody dat apod. Neukládám sem nic důležitého. Mažu nejpozději po týdnu nepoužívání.

Soubory smaz*, test* a *.tmp v libovolném adresáři:Pracovní, dočasné a testovací soubory. Při ukončení nebo přerušení práce v nich nikdy nenechávám důležitá data. Nepracuji-li zrovna s nimi, mohou se kdykoliv smazat.

Adresář ~/testy: Data různých testů. Povede-li se test, přesunu jej do vlastního adresáře, jinak zůstává zde. Mažu soubory, jejichž účel jsem zapomněl.

Zápis relace (sezení)

Většina grafických systémů a mnoho programů umožňuje zapsat stav relace a poté jej obnovit. Je příjemné, když večer skončíme s prací a ráno najdeme v prohlížeči stejné webové stránky, v editoru stejné soubory, kde kurzor stojí na stejných řádcích, a dokonce i přehrávač se postaví na tu skladbu, na které včera skončil.

CS24_early

Pokud svůj počítač vypínáte nebo přecházíte od jedné práce k jiné, čas investovaný do nastavení správy relací se vyplatí.

A to je pro dnešek vše. Příště se opět vrátíme do témat UNIXového světa.

Byl pro vás článek přínosný?

Autor článku