Hlavně v tom, že od okamžiku, kdy inotify zaznamená změnu, do okamžiku, než to zpracuje rsync, uběhne nějaká doba, po kterou se ten soubor může dál měnit, být smazán, znovu vzniknout. Může se zdát, že to ničemu nevadí, že to nakonec bude ve správném stavu, ale to právě záleží na okolnostech. Třeba asi nebude chtít synchronizovat soubor, do kterého se ještě zapisuje, takže budete čekat na jeho uzavření. Jenže než ho po uzavření stihnete zkopírovat, začne se do něj znovu zapisovat. A na druhé straně pak budete mít nějakou podivnou rozpracovanou verzi souboru, který v té podobě ani ve zdrojovém adresáři nikdy nemusel existovat. Navíc nevím, jak se bude rsync tvářit na soubor, který se mu mění pod rukama.
Toz to se resi prave tim, co jsem napsal. Jestlize uz mi bezi rsyncovany skript, tak se misto spusteni dalsi kopie zapise soubor do seznamu, ktery se preda nasledujicimu behu. Vas prispevek me akorat privadi k tomu, ze se v tom seznamu budou muset overovat duplicity, aby se nersyncovalo do aleluja porad dokola uplne zbytecne.
Bohuzel me nenapada, jak to dostatecne inteligentne udelat, aby se nesyncovaly ty otevrene soubory a zaroven zajistit, aby se aspon obcas syncovaly. Snad leda pridani timeoutu u souboru, u kterych v seznamu byla nalezena duplicita, pricemz by take bylo dobre si poznamenavat cas, kdy se tam ten soubor dostal poprve a pokud tam trci jiz po urcitou dobu, tak ho syncovat i otevreny/prubezne modifikovany, i kdyby trakare padaly. Takze bychom asi skoncili u kombinace cronjobu a inotify spousteneho skriptu. Byl by asi dost opruz ten skript nebo spis skripty napsat.
Ostatne s otevrenymi a casto prubezne modifikovanymi soubory bude zapolit i nejaka ta sync utilita od zmineneho OneDrive anebo Disk Google.
Ostatne sync souboru, ktere tam trci uz vic, jak urcity cas, by sel asi oblafnout pres parametr --modify-window.
30 Odpovědí
4639 Zhlédnutí