Rsync – inteligentní kopírování souborů (diskuse)

[Jendа]

rsync také často používám, například na nahrávání webů na server nebo na již zmíněné zálohování.

Několik poznatků:

• Zálohuji šifrovaně do encfs a kvůli bugu v encfs rsync kopíruje vždy všechno znovu. Dá se to vyřešit patchnutím rsyncu.
• Když je na druhé straně SSH, kromě v článku zmíněného

  rsync --rsh="ssh -l root" soubor1 soubor2 192.168.1.15:/cílový-adresář

  lze též použít podle mě přirozenější

  rsync --rsh="ssh" soubor1 soubor2 root@192.168.1.15:/cílový-adresář

• Rsync se dá použít i na přenos celého systému (záloha, instalace na nový počítač podle šablony…). Pak se ještě hodí parametr --numeric-ids.

[VSi]

U zálohování pomocí čistého rsync je dosti nepříjemná absence historie. Nejhorší je, když se v provozních datech smaže nějaký soubor, a pak se pustí rsync, který zálohovanou verzi toho souboru smaže i na záložním médiu. Je lepší použít alespoň volbu --backup-dir nebo i --link-dest, která vytvoří pomocí hardlinků kompletní "snapshot". Ideální by bylo rsync zkombinovat s filesystemem typu ZFS nebo BTRFS, kde jde tvořit "levné" snapshoty. Bohužel linux zatím takový stabilní (!) FS nemá.

Nakonec člověk pro zálohování stejně skončí u hotového řešení typu dirvish nebo rsnapshot, které mají obvykle dobře ošetřené i mezní situace typu výpadek v půlce zálohování, pokus o paralelní spuštění, mazání starých verzí a podobně. Pro větší množství souborů (stovky tisíc) pak přichází problémy, protože jen mazání staré verze na ext3 může trvat desítky minut.

Rsync lze dobře používat i z Windows vč. ssh klíčů nebo i obdoby ssh-agenta - putty pageant. Jediný problém je se znakovou sadou v názvech souborů, což se dalo řešit volbou --iconv u novějších verzí, nebo dřív nebo opatchovanými knihovnami cygwinu.

[Jendа]

Já historii tak nějak moc nedržím…

[VSi]

Jestliže mluvíme o zálohování, pak by taková záloha měla chránit i před nechtěným smazáním. Než si uvědomím, že jsem něco nechtěně smazal, může už zálohování (spíš synchronizace) proběhnout a soubor je pryč. Ale uznávám, že ne vždy tohle musí vadit.

[pht]

U zálohování pomocí čistého rsync je dosti nepříjemná absence historie.

Jeden program, jeden úkol. Historii můžete držet jednoduše např. gitem a to celé rsyncovat (nebo v případě gitu stačí použít jeho vlastní push).

[pavlix]

No když srovnám rsync+git a rdiff-backup, tak nevim nevim, teda. Filosofie jednoúčelových nástrojů je fajn, ale tady bych dal přednost filosofii vhodnějšího nástroje pro daný účel, tzn rsync na mirroring/kopírování a rdiff-backup (či stejně schopnou alternativu) na inkrementální zálohy.

[pht]

Záleží jestli je vaše filozofie založená na zálohování nebo na obnovování. :)

[pavlix]

Neumím si představit, že by soudný člověk založil filosofii pouze na jedné z těchto operací, tedy za předpokladu, že to není přímé zadání :).

Slyšel jsem o případech, kdy produkt byl určený pouze k zálohování a obnovovací nástroj nebyl součástí, ale považuju to za kuriozitu :).

[pht]

No zní to jako špatný vtip ale viděl jsem už příliš mnoho podomácku udělaných zálohovacích řešení, které měly "jen" jednu vadu, a sice že až přišlo na obnovu dat tak se zjistilo, že záloha není použitelná částečně nebo vůbec.

Proto jsem to soustředění se na obnovu dat myslel spíš tak, že mě nezajímá jen jestli nějaký nástroj umí cosi zálohovat/archivovat, ale zajímají mě i věci např.:

1. Jak složité je obnovit verzi z nějakého konkrétního data
2. Jak složité je nechat si zobrazit rozdíly mezi nějakými dvěma zálohami
3. Jak mi nástroj garantuje integritu dat
4. Jak dlouho trvá obnova inkrementální zálohy
5. Jak moc je nástroj odolný vůči poškození nějaké inkrementální zálohy

... atd. U gitu zhruba vím, jak se věci mají. Možná by někdo erudovaný mohl doplnit znalostmi o rdiff-backupu.

[pavlix]

Chápu.

Extrémně erudovaný nejsem... git má nevýhodu (v případě sw projektů výhodu) v tom, že pracuje na projektu jako celku. Poškození části může za určitých okolností dělat problémy při obnovení jiné části.

Rdiff-backup je v tomhle daleko jednodušší, ukládá celé soubory, metadata a binární diffy historie.

Navíc git je stavěný na explicitní revize, rdiff-backup, udělá revizi každým spuštěním, takže žádné commit messages, žádné konflikty apod.

Git je optimalizovaný na textové zdrojáky, rdiff je univerzálnější.

Takže ve výsledku obojí funguje, každé trochu jinak.

[casey]

tohle řeší rdiff-backup. Vracet se můžeš dle libosti

[bender]

jojo, rdiff-backup je moje číslo jedna. každý den mi tak probíhá automatická záloha několika serveru, v kombinaci s snapshoty lvm je to pohoda a obnovení zálohy z konkrétního dne je pak taky prýma věc. ještě malý odkaz na zajímavý projekt, který sem ještě neměl čas zkoušet - archfs, připojíte zálohu rdiff-backup jako souborový systém a když potřebujete získat konkrétní soubory ze zálohy, tak to může bejt taky lahoda.

[Heron]

ArchFS funguje. Je to kapku pomalejší, ale lepší než se hrabat v příkazech rdiff-backup.

[pavlix]

Neříkám, že je to nějaký zázrak, ale rdiff-backup má příkazy ještě celkem srozumitelné a použitelné. To už bych to spíš do něčeho zabalil než na to jít takhle.

[m;)]

time for zfs send/receive ?

[VSi]

Jo, přesně tak. I když pro začátek by bohatě stačily aspoň levné snapshoty (nezpomalující, ne ve stylu LVM2) a rsync.

[loki]

Dekuji. Pekny clanek.

[12345]

Pěkný článek. Ještě bych zmínil (možná) překvapivou citlivost rsync na přítomnost koncových lomítek. Z manuálu:

              rsync -avz foo:src/bar /data/tmp

       This would recursively transfer all files from the directory src/bar on the machine foo into the /data/tmp/bar
       directory  on  the  local  machine.  [...]

              rsync -avz foo:src/bar/ /data/tmp

       A  trailing  slash  on the source changes this behavior to avoid creating an additional directory level at the
       destination.  You can think of a trailing / on a source as meaning "copy the contents of  this  directory"  as
       opposed  to  "copy  the  directory  by name", but in both cases the attributes of the containing directory are
       transferred to the containing directory on the destination.  In other words, each of  the  following  commands
       copies the files in the same way, including their setting of the attributes of /dest/foo:

              rsync -av /src/foo /dest
              rsync -av /src/foo/ /dest/foo

[Ruža Becelin]

Jesti se nemylim, tak takhle se chova i cp, mv a dalsi.

[Ash]

Mýlíte se cp -r src/ dst je totéž jako cp -r src dst. Ekvivalent k rsync src/ je cp -r src/*.

[Ruža Becelin]

Jo, to sedi, ted jsem si to zkusil...

[Bill Gates]

Pekny clanek o rsync, sam rsync masivne pouzivam - prevazne spoustim z cronu jednou za cas na geograficky oddelene zalohovani serverů, mirroring atd. Luxus. Jen by me hodne u rsync bodla jedna funkce, ktera by se hodila pro prenos zmen v hodne dlouhych souborech, aby se soubor neprenasel cely porad dokola. Ale mozna jsem to nekde prehlidl v man rsync, ale hledal jsem to uz nekolikrat a nenasel. Idealni vec - rozsekat soubor jakoby virtualne na bloky treba po 5M (v pripade treba 1G souboru) a prenaset jen zmenene bloky. To by usetrilo u dlouhych souboru konektivitu jako kraaaaaava. Nebo existuje nejaka takova nadstavba nad rsync? I kdyz pravda nemam problem si to napsat, az na cas, ktereho se mi posledni dobou rapidne nedostava.

[hufhendr]

Já naopak rsync objevil právě pro kopírování opravdu velikých souborů, kdy se při výpadku spojení přenáší pouze chybějící data. Rsync hlídá integritu přenášeného souboru a při druhém spuštění případně doplní jen chybějící bajty v případě, že jsou potřeba.
Až budu doma u počítače, vykopíruji sem konkrétní příkaz s parametry.

[osvc1]

...bodla jedna funkce, ktera by se hodila pro prenos zmen v hodne dlouhych souborech, aby se soubor neprenasel cely porad dokola ...

tomu ted nerozumim, rsync je tu prave kvuli tomu a vpodstate nedela nic jineho ?

[Filip Jirsák]

Idealni vec - rozsekat soubor jakoby virtualne na bloky treba po 5M (v pripade treba 1G souboru) a prenaset jen zmenene bloky.

rsync to ve skutečnosti dělá ještě chytřeji – spočítá si kontrolní součet bloku, a na druhou stranu přenese jenom ten. Na druhé straně pak hledá blok se stejným kontrolním součtem – pokud takový najde (i na jiném místě, než kde je u zdrojového souboru), má data pro ten konkrétní přenášený blok. Takže i pokud třeba na začátek souboru přidáte jeden bajt, přenese se jen ten jeden bajt a kontrolní součty všech bloků. Nebo se podívejte na popis algoritmu rsync.

[Bill Gates]

tak to je mazec, diky ze jste me vyvedli z omylu... ja to hledam kde se to nastavuje jako prepinac a on to rsync davno dela automaticky ... dik za nakop :D mrknu

[hufhendr]

Tady je ten slibovaný příkaz
time rsync --bwlimit=150 --progress -avhcSe ssh * server:/adr/

[pht]

Pár poznámek.

V praxi však může být rsync mnohem efektivnější. Pokud už totiž v cílovém adresáři existuje některý z kopírovaných souborů, přenášejí se pouze rozdíly, zatímco cp kopíruje vždycky všechno.

Tohle není úplně správně. Program cp se dá nastavit taky tak, aby nepřepisoval (nebo nepřepisoval aktuální). Rsync umí kromě datumu porovnat i checksum (i když tato volba se zřídka využívá), aby poznal co je v cílovém adresáři potřeba přepsat. Hlavní přínos rsyncu v této oblasti je v tom, že umí přenášet pouze rozdíly i v rámci jednoho souboru. Takže když někdo do 20mb souboru připíše doprostřed "ahoj", bude přeneseno pouze to "ahoj" plus nějaká malá metadata. Tohle ale funguje jen v přenosech po síti, protože při přenosu z disku na disk se nic neušetří.

rsync --rsh="ssh -l root" soubor1 soubor2 192.168.1.15:/cílový-adresář

Stačí použít

rsync cosi root@kdesi:/kamsi

... protože rsync používá ssh standardně.

Ve většině případů je nejvhodnější pro přenos na vzdálený počítač použít ssh. Jsou však případy, kdy je vhodné použít rsync server. Typické použití je například adresář /usr/portage v distribuci Gentoo. ... Díky tomu, že utilita rsync přenáší pouze rozdíly, je její použití pro podobné účely velmi vhodné.

Tohle je trochu zamotaný výklad. Rsync přes ssh taky přenese jen rozdíly. Výhoda rsync démona je v tom, že nešifruje data a je tedy o něco rychlejší a taky "psychologicky" že lidi nějak neradi poskytují anonymní ssh účty.

Promazání nadbytečných souborů zvláště na pomalé lince může trvat tak dlouho, že rsync havaruje (firewall ukončí dlouho trvající nepoužívané spojení).

Tohle by neměl být problém kvůli tomu že neaktivní TCP spojení se umí udržovat samo na živu (keepalive). Při spojení přes ssh je to zaplé.

[osvc1]

ja jsem nepochopil, jak je to s tim rsync-demonem. Podle ceho v prikazech vidim se se pouziva rsync demon a kdy to jde pres ssh?

[core]

podle toho, jaky ma adresa format

pro user@kdesi:/kamsi se pouzije ssh

pro user@kdesi::modul/kamsi se pouzije rsync protokol, tj. musi tam bezet rsync demon

viz. manual :)

[Filip Jirsák]

Lokálně lze rsync použít podobně jako cp. Ve výsledku je jak volání cp, tak rsync ekvivalentní. V praxi však může být rsync mnohem efektivnější. Pokud už totiž v cílovém adresáři existuje některý z kopírovaných souborů, přenášejí se pouze rozdíly, zatímco cp kopíruje vždycky všechno.

To obecně platí jen v případě, kdy je zápis na disk výrazně pomalejší, než čtení. rsync ty rozdíly musí nějak zjistit, musí tedy celý cílový soubor přečíst. Pokud tedy bude čtení stejně rychlé, jako zápis, bude rsync pomalejší – musí celý soubor přečíst a změněné části pak zapsat, cp jen celý soubor zapíše. Pokud jsou ty soubory úplně jiné, bude také rsync pomalejší – rsync i cp musí celý soubor zapsat, ale rsync jej před tím ještě musí celý přečíst. Proto je rsync výhodný hlavně při přenosu přes síť, kdy se toho sice na obou stranách musí udělat víc, než při obyčejném cp, ale tahle ztráta se více než vrátí tím, že pak stačí po síti přenést menší objem dat.

[CEST]

Pokud jsou ty soubory úplně jiné, bude také rsync pomalejší

To zrejme neni pravda, pokud samozrejme nevynutis porovnavani pouze checksumem (-c). On totiz rsync kontroluje cas zmeny, velikost a checksum. Takze kdyz budou soubory uplne jine (velikost a cas zmeny), tak zacne rovnou kopirovat, ne?

Osobne se mi na rsyncu libi moznost navazovani spojeni - kopiruje se, spojeni padne, tak se spusti kopirovani znova a pakracuje se, kde to spadlo. Ja pouzivam obvykle interaktivne -P (--progress --partial).

[pht]

Pokud tedy bude čtení stejně rychlé, jako zápis, bude rsync pomalejší – musí celý soubor přečíst a změněné části pak zapsat, cp jen celý soubor zapíše.

Na to už mysleli taky.

       -W, --whole-file
              With this option rsync's delta-transfer algorithm  is  not  used
              and  the  whole file is sent as-is instead.  The transfer may be
              faster if this option is used when  the  bandwidth  between  the
              source  and destination machines is higher than the bandwidth to
              disk  (especially  when  the  "disk"  is  actually  a  networked
              filesystem).   This is the default when both the source and des-
              tination are specified as local paths, but  only  if  no  batch-
              writing option is in effect.

[CEST]

Mne osobne v rsyncu chybi jedna jedina vec, kterou bych ale dost casto vyuzil. Docela rad bych mel remote-remote copy. Chtel bych ze svoji masiny kopirovat z jednoho rsync serveru na jinej rsync server. Bohuzel tohle nejde, jedna strana musi byt vzdy local.

Ted to resim tak, ze se pripojim na jeden server pres ssh a nastavim remote tunnel pres svoji masinu na cilovy host (protoze cilovy host neni ze zdrojoveho primo dostupny, musim to hnat pres svoji masinu) a na zdrojovem hostu pak nadefinuju -e 'ssh -p tunelport'. Ale neni to ono, lepsi by bylo rsync host1:/data/ host2:/data/

[Filip Jirsák]

Aneb další příspěvek do debaty „NAT ničemu nevadí“. Chápu, že mohou nastat případy, kdy oba servery mají veřejnou IP adresu ale „nevidí“ na sebe kvůli nastavení firewallu, ale pokud se mezi nimi mají přenášet data a firewall to nepovolí, je to spíš chyba nastavení firewallu.

[CEST]

No, to je spis tak, ze admin stanice ma na firewall by default SSH otevrene ven. A kdyz chci pak jednou zkopirovat neco z DMZ serveru A na INT server B, dalsi den nezo z INT serveru C na DMZ server D, nebo proste behem dne potrebuju neco zkopirovat nekolikrat, ale pak uz ne, tak kvuli tomu nebudu kazdej den menit firewall. Samozrejme, ze pro pravidelne prenosy je firewall otevreny, to bych se vubec nepsal. Slo mi prave o ty nepravidelne prenosy, kdyz ale nechce data tahat nadvakrat.

[Filip Jirsák]

Tu poslední větu nechápu. Tak buď je možné navázat přímé spojení mezi oběma servery, a data pak půjdou přímo a jednou. A nebo to možné není, a je potřeba data stáhnout ze serveru na stanici a pak ze stanice poslat na druhý server – tedy data půjdou dvakrát, a to bez ohledu na to, jestli to rsync umí udělat sám, nebo je potřeba si je meziuložit.

[pht]

Chtel bych ze svoji masiny kopirovat z jednoho rsync serveru na jinej rsync server. Bohuzel tohle nejde, jedna strana musi byt vzdy local.

ssh server1 'rsync /data/ server2:/data'

[Ash]

V tomto případě je local server1, to že je příkaz spuštění přes ssh na tom nic nemění.

[pht]

Pointa je "co jiného by ten bájný server-server rsync udělal?"

[Ash]

Bájný server-server rsync by se rozhodně nehlásil přes ssh na jiný server aby odtamtud na sebe pouštěl rsync, to je jako drbat se pravou rukou za levým uchem.

[pht]

No, ale to není na sebe, nýbrž na server2. Což vystihuje přesně požadavek "chci aby můj počítač přikázal serveru1 sesynchronizovat se se serverem2".

[Ash]

Bájný server-server rsync by se rozhodně nehlásil přes ssh na jiný(tedy nikoliv sebe) server

A ten "požadavek" nijak neodpovídá architektuře "server-server" :(

[pht]

bleh...

Bájný server-server rsync by se rozhodně nehlásil přes ssh na jiný server aby odtamtud na sebe pouštěl rsync, to je jako drbat se pravou rukou za levým uchem.

[Ash]

Aha, každý jsme to pochopili jinak. Já jako "rsync server" pochopil server, kde běží jako služba rsync, nikoliv jako server účastnící se kopírování.

Chtel bych ze svoji masiny kopirovat z jednoho rsync serveru na jinej rsync server.

Pokud by šlo jen o to spustit rsync na vzdáleném server (nikoliv rsync serveru) pak samozřejmě stačí to co jsi napsal, na server se přihlásit a spustit tam rsync.

[Dalibor Smolík]

Pokud už totiž v cílovém adresáři existuje některý z kopírovaných souborů, přenášejí se pouze rozdíly, zatímco cp kopíruje vždycky všechno.
cp s přepínačem -u by měl udělat totéž.

[Filip Jirsák]

Tím všechno bylo asi myšleno celé soubory – cp to porovnává jen na úrovni souborů, rsync jde i dovnitř souboru a přenáší jen změněné části.

[Petr Bravenec]

Tím "všechno" bylo především myšleno, že nemá smysl se zabývat přepínači příkazu cp v článku o rsync. Přiznám se, že cp používám často, ale pouze v těch nejjednodušších případech, takže přepínače detailně neznám. Než bych studoval manuál, sáhnu po léty osvědčeném

find . -print | cpio -pvudm /kam-to-pude

které mi, na rozdíl od různých přepínačů cp, fungovalo už na SVR3. Případně sáhnu po rsync, který mám nastudovaný lépe, než cp.

[Dalibor Smolík]

Rozumím, je to jen o zvyku. Já používám cp -ru, takže to zaznamená novější verze souborů ve všech podadresářích.

[disorder]

jedna vec nikde nebyva spomenuta: ako skopirovat do adresara s medzerami -- je nutne escapovat dvakrat (napr. "server:~/adresar\ s\ medzerou/")

[pavlix]

To co píšeš escapuje ty mezery v podstatě jenom jednou, shell ti to interpretuje úplně stejně jako bez těch lomítek, viz speciální znaky, které se interpretují i mezi uvozovkami.

[Stanislav Brabec]

Rsync, zdá se, neumí rozumně řešit přesun souborů. Přejmenované nebo přesunuté soubory nenajde a kopíruje je celé.

Já ro řeším tak, že před reorganizací vytvořím v synchronizovaném stromu pomocný adresář, tam nahardlinkuji všechny soubory, pustím rsync s parametrem -H, pak provedu reorganizaci, opět pustím rsync s parametrem -H, pak pomocný adresář smažu, a pustím rsync naposled.

[jirkaehm]

Kolik souboru takto synchronizujes? a co napriklad kolize jmena u souboru?
to musi byt uplne silene narocne na diskove operace :)

[pavlix]

Přijde mi, že na to rsync nemá tak úplně efektivní prostředky, takže celkem chápu, že přesuny souborů ignoruje a schvaluju to.

[mj41]

Rsync s --exclude-from=./ignore-list.txt je taky fajt. Na každém řádku je jedna položka, která se má ignorovat.

Používám to tak, že v cronu si tahám soubory k sobě na server a přidávám je do seznamu polože, které se již nemají příště rsyncovat. Tím můžu některé soubory u sebe vymazat a už se mi znovu nenahrají.

V kombinaci s automatickým rozbalováním se to hodí . Ale aby to bylo úplně vončo, tak jsem si musel napsat auto-unrar, který exclude-listy generuje ještě o něco inteligentněji.

[Xerces]

Ahoj Rsyncguruové, osobně používám rsync taky k zálohám vybraných adresářů /home /etc /mnt na druhý počítač. Aktuálně zrovna řeším situaci, kdy bych chtěl rsync použít na synchronizaci vývojář www <-> server www. Resp. napsal jsem stránky v php a umístil na server a pro "hloupé" klienty chci udělat baťáky, který spustí rsync s takovými parametry že: 1. Stáhnou aktuální stav ze serveru (tak to je easy), 2. Nahrajou upravené soubory na server. Ovšem v bodě 2 bych to chtěl udělat odolné proti tomu, kdyby omylem někdo na straně klienta do toho adresáře hrábnul tím způsobem, že by tam přidal/přejmenoval/ubral nějaké soubory. Prostě chci umožnit jen modifikaci obsahu souborů již existujících na serveru, bez toho aniž bych je musel v tom baťáku vyjmenovat. Nevěděl by někdo kombinací parametrů?

[Jiří Svoboda]

Jestli jsem správně pochopil tvůj dotaz, tak ti stačí výchozí chování. Dokud nezadáš některý z parametrů --delete, tak se ti na serveru nic nesmaže.

[Ash]

Nestačí mu výchozí chování, protože ve výchozím chování se na server nahrávají i nové soubory, což on nechce, on chce jen existující aniž by je musel explicitně vyjmenovat.

[Xerces]

Ahoj, přesně tak. Výchozí chování mi zajistí jen ten delete ale nikoliv nové soubory omylem nahrané do synchronizovaného adresáře. No asi těch 50 souborů vyjmenuju jako parametr, ale škoda, takhle budu muset do BAT hrábnout vždy když budu chtít na server přidat nový soubor.

[Ash]

Možostí je víc, nějaké míře specifikace souborů které chcete synchronizovat se nevyhnete, protože počítač nemá křišťálovou kouli. Nabízí se parametry --include, --include-from, --files-from, díky čemuž můžete určit buď pattern, nebo přímo konkrétní soubory v nějakém konfiguračním souboru, ne přímo v tom... eh... "baťáku" (na linuxch na rozdíl od DOS říkáme skript).

[Xerces]

No ono ten klient rsync bude na Windows. Linuxovej je ten cílovej server. Jinak k té křišťálové kouli. Ten klient by to mohl nějak testovat tak, že by si nejdříve zjistil, zda ten soubor který se pokouší na server přenést již na serveru existuje a pokud nikoliv tak by se na něj vybodnul, něco jako --transfer-only-existing-on-target. Každopádně díky všem za cené nápady.

[Ash]

A co --existing?

[Petr Bravenec]

Něco podobného bych asi řešil trochu jinak:

1. Vývojaře donuťte pracovat v gitu. Získáte tak dobře zdokumentovanou historii celého projektu, budete vědět, za co je kdo zodpovědný.

2. Rsync můžete ponechat, velmi snadno se nastavuje. Ale k podobné funkci se dá donutit i git přes hooks - můžete například říci, že větev "vyvoj" se commitem nahraje na test.domena.cz a větev "master" se nahraje na www.domena.cz (aspoň doufám, že nekecám, tuto část gitu jsem jen teoreticky louskal v manuálu).

Je to složitější, ale dnes už si nedovedu představit ani tvorbu jednoduché internetové vizitky bez verzovacího systému. Ale je možné, že navrhuji jít s kanónem na vrabce.

[Xerces]

Tak ono se nejedná o vývojáře v pravém slova smyslu, ale o uživatele, který mění obsah stránek editací textového souboru. Tento uživatel skutečně není schopen ničeho jiného než otevřít soubor z Folderu na ploše, zeditovat ho a odpálit skript. Nepřál bych vám jej učit git

[Jendа]

Nemohl by ten skript automaticky obsloužit i GIT?

[pavlix]

Mno... git je systém správy verzí... tak jak to píšeš ty, funguje v podstatě wiki. Tzn systém správy verzí nějakého textového obsahu, který je uživatelsky přívětivý.

V podstatě by ti stačilo, kdyby ten git fungoval automaticky, což jde, když se vyhneš kolizím. Můžeš index používat jako náhled změn a commit+push jako potvrzení. Navíc na druhý straně napíšeš triviální hook, který reaguje na příchozí nové verze. Na 99% je tohle už naimplementováno jako nějaký opensource.

[Sagart]

Ahoj, prosím o radu. Rád bych synchronizoval jeden adresář na desktopu s adresářem na flash disku.

1. Jak udělat to, aby se mi udržovaly soubory v daném adresáři synchronizované = totiž, když jsem doma, aktualizuji soubory na desktopu, a když doma nejsem, aktualizuji soubory na flash disku. TZN abych měl jak na flash disku tak na HD desktopu současně stále nejaktuálnější soubory?

2. Je nějaká možnost, jak napsat script právě na ten flash disk, abych, jakmile ho připojím do PC se daný skript automaticky spustil a výše popsanou (1) synchronizaci provedl? Bez nutnosti skript spouštět manuálně...

Díky předem za nápady.

pzn: kdyby mi někdo takový script napsal, rozhodně bych nepohrdl

[Filip Jirsák]

Zeptejte se radši v Poradně, tady dotaz nikdo hledat nebude.

Možnost mít automaticky spouštěný program na externím médiu mají určitě Windows, a je s tím spousta zábavy, protože takový program nemusí jen nudně synchronizovat data, ale může třeba uživateli vše smazat. Můžete to ale udělat opačně, na počítači si pomocí udev pravidel nastavte, aby se při zasunutí toho flash disku spustla synchronizace.

[pavlix]

Oboustranná synchronizace filesystému je hodně velký zvěrstvo :). Pokud by to bylo na dokumenty nebo nějaké menší množství souborů, asi bych volil decentralizovaný systém správy verzí (i když se většina jeho funkcionality třeba vůbec neuplatní). Čistě automatická synchronizace na tohle nefunguje, pokud někdo udělá změnu na dvou místech, ty správy verzí s historií už to umějí za pomoci uživatelské interakce řešit.

[m;)]

ked uz sme pri tom, skusim poradit este velmi sikovny program na obojsmernu synchronizaciu -- http://www.cis.upenn.edu/~bcpierce/unison/ :)

[Sagart]

Ok, díky oběma.