Tervete kataloogipuude haldus ja jagamine

See peatükk koondab üheks töövooks käsud cp, rsync, scp, tar, zip ja Git-i loogika. Mõte ei ole korrata kõiki üksikkäske, vaid anda tervikpilt: mida teha siis, kui sul on vaja hallata või jagada tervet projektipuud.

Loogika

Kui liigud üksikfailidest edasi tervete kaustapuudeni, siis küsimus ei ole enam ainult “kuidas kopeerida üks fail”, vaid:

1. kas tahan teha kohaliku koopia
2. kas tahan saata puu teise masinasse
3. kas tahan teha ühest hetkest arhiivi
4. kas tahan jagada seda nii, et hiljem saaks muudatusi jälgida
5. kuidas kontrollida, et tulemus sai õige

Just siin lähevad tööriistad oma tugevuste järgi lahku.

Kiirülevaade

Eesmärk on valida tööriist terve projektipuu jaoks: koopia, sünkroon, arhiiv või muudatusajalugu.

Tüüpilised algaja vead

• kasutatakse sama töö jaoks juhuslikult eri tööriistu, mõtlemata eesmärgile
• arvatakse, et scp -r ja rsync on alati sisuliselt sama
• ei kontrollita, kas koopia sisaldab ka peidetud faile või õigeid metaandmeid

Millal millist tööriista kasutada

• cp -R sobib, kui tahad samas masinas teha lihtsa koopia
• rsync -av sobib, kui tahad korduvat sünkroonimist või varundust
• scp -r sobib, kui tahad kiiresti terve puu SSH kaudu teise masinasse saata
• tar -czf või tar -cJf sobib, kui tahad ühest hetkest ühte arhiivifaili
• zip -r sobib, kui jagad sisu inimestega, kes töötavad eri süsteemides
• Git sobib, kui tahad mitte ainult jagada tulemust, vaid ka jälgida muudatusi ajas

Kohalik koopia: cp

Kui vajad ühekordset koopiat samas masinas, siis alusta lihtsast käsust:

cp -R projekt projekt-koopia

See on hea valik siis, kui:

• tahad kiiresti proovida midagi teises koopias
• tahad teha enne suuremat muutust kohaliku varu
• allikas ja sihtkoht on samal masinal

Kui metaandmed loevad, siis GNU/Linuxis kasutatakse sageli:

cp -a projekt projekt-koopia

Seda tasub võtta kui “säilita nii palju kui võimalik”. Eri süsteemid ei käitu siin alati täpselt ühtemoodi.

Korduv sünkroonimine: rsync

Kui sama puud liigutatakse korduvalt, siis rsync on tavaliselt parem kui cp või scp.

rsync -av projekt/ projekt-varu/

Selle käsu tugevused:

• saadab uuesti peamiselt muutunud sisu
• säilitab struktuuri ja metaandmeid paremini
• sobib nii lokaalseks kui kaugsünkroonimiseks

Oluline kaldkriipsu loogika:

• projekt/ tähendab enamasti “selle kausta sisu”
• projekt tähendab sagedamini “see kaust tervikuna”

Enne suuremat kopeerimist on väga mõistlik teha dry-run:

rsync -avn projekt/ projekt-varu/

Kui siht on serveris:

rsync -av projekt/ kasutaja@server:/srv/projekt/

Kiire ülekanne teise masinasse: scp

scp on hea siis, kui tahad lihtsalt midagi kiiresti teise masinasse saata:

scp -r projekt kasutaja@server:/tmp/

See on praktiline, kui:

• vajad ühekordset üleslaadimist
• sul ei ole vaja keerukamat sünkroonimisloogikat
• SSH on juba seadistatud

Kui tahad võimalikult palju säilitada ajatemplite ja õiguste kohta, kasuta sageli:

scp -rp projekt kasutaja@server:/tmp/

Üks fail kogu puust: tar, tgz, zip

Kui tahad tervest puust teha ühe jagatava faili, siis sobib arhiiv:

tar -czf projekt-2026-04-13.tgz projekt/
tar -tf projekt-2026-04-13.tgz

See on hea valik siis, kui:

• tahad saata ühe faili
• tahad võtta kindla hetke snapshot'i
• tahad arhiivi enne lahti pakkimata kontrollida

Kui adressaadil on tõenäoliselt Linux või macOS, on tar.gz või .tgz sageli loomulik valik.

Kui adressaadid on väga eri keskkondades, on zip mugav:

zip -r projekt.zip projekt/
unzip -l projekt.zip

Mis saab õigustest ja omanikest

Suure puu halduses on oluline eristada nelja asja:

• faili sisu
• failipuu struktuur
• õigused
• omanikud ja grupid

Rusikareeglid:

• cp -R ja scp -r lahendavad eelkõige sisu ja struktuuri
• rsync -a ja tar hoiavad Unix-laadset metaandmete pilti paremini koos
• zip sobib rohkem jagamiseks kui täpseks Unix-i säilitamiseks
• Git ei talleta tavaliselt omanikku, gruppi ega ajatemplite ajalugu

Git talletab hästi:

• faili sisu
• kataloogistruktuuri
• tekstimuudatuste ajaloo
• täidetavusbitte olulisemates juhtudes

Git ei ole varukoopia-arhiiv igas mõttes. See ei asenda tar-i ega rsync-i, kui tähtis on kogu failisüsteemi metaandmete võimalikult täpne ülekandmine.

Jagamine: arhiiv või GitHub

Kui eesmärk on lihtsalt “saada see tervik teisele inimesele”, siis mõtle nii:

• üks ühekordne hetkeseis: tar.gz või zip
• korduv uuendamine serverisse: rsync
• ühine arendus ja muudatuste ajalugu: Git + GitHub

Seega:

• andmepuu või snapshot: arhiiv
• deploy või varu: rsync
• koostöö ja versioonihaldus: Git

Kuidas kontrollida, et said õige asja

Suure puu juures on kontroll sama tähtis kui kopeerimine ise.

Kõige praktilisemad kontrollid:

• vaata failide arvu ja suurust
• loe arhiivi sisu ilma lahti pakkimata
• tee rsync-iga dry-run
• võrdle vähemalt mõne võtmefaili räsi

Näited:

du -sh projekt projekt-koopia
find projekt | wc -l
find projekt-koopia | wc -l

tar -tf projekt-2026-04-13.tgz | head
unzip -l projekt.zip

shasum -a 256 projekt/README.md projekt-koopia/README.md

Linuxis on sama loogika sageli kujul:

sha256sum projekt/README.md projekt-koopia/README.md

Soovitatud töövood

1. Enne riskantset muutust

rsync -av projekt/ projekt-varu/

2. Saada tervik serverisse

rsync -avn projekt/ kasutaja@server:/srv/projekt/
rsync -av projekt/ kasutaja@server:/srv/projekt/

3. Tee jagatav snapshot

tar -czf projekt-$(date +%F).tgz projekt/
tar -tf projekt-$(date +%F).tgz | head

4. Jaga koostööks

git status
git add .
git commit -m 'Valmista projekt jagamiseks'
git push

Viimase töövoo detailid tulevad eraldi Git-i peatükis.

Minitest

1. Tee ühest testkaustast kohalik koopia käsuga cp -R.
2. Tee samast kaustast rsync -avn dry-run teise kausta.
3. Paki sama kaust .tgz faili ja kuva selle sisu käsuga tar -tf.
4. Mõtle ühe näite põhjal, kas sinu eesmärk on snapshot, sünkroonimine või koostöö ajalooga.