Ale jo, já těm nářkům věřím (však taky píšu, že tohle provozuju tak trochu "natruc", s jištěnou zálohou), ale zajímá mě to technicky. Pokud vím GG používá SQLLite, tedy zpracování je transakční a mělo by z podstaty věci být stavěno na takovéto "poruchy". SQL servery běžně dělají replikace na jiné lokality, "za chodu". Takže mě jen zajímá, v čem je GG odlišný, že mu Dropbox nesvědčí.
Mohu te ujistit, ze repliakce databazi se provadi zcela jinymi technikami, nez souborovy cloud.
Sqlite je velmi odolna databaze, ale to funguje jen tehdy, kdyz bezi na lokalnim pocitaci, kde mas kontrolu i nad takovymi vecmi, jako kdy pocitac skutecne fyzicky ulozil data na disk. (data flush)
Bez toho jde bezpecnost dat do haje, uz i pri behu ze serveroveho sdileni v lokalni siti mohou nastat neprijemne komplikace.
Ale opravdyu by mne zajimala databaze, ktere by nevadilo, ze ma kus databaze v nove verzi, a kus ve stare. Jsou i databaze, kde i kazda tabulka v jedne databazi potrebuje hned nekolik samostatnych souboru, a databaze je vlastne obsah celeho adresare. Tam si fakt nemuzes dolovolit, aby treba dropbox stihl sesynchronizovat jen polovinu.
Sqlite ma sice data v jednom souboru, ale pri transakcni praci pouziva journal soubor, aby pri pripadnem rallbacku transakce mohl databazi uvest do puvodniho stavu. Za normalni situace pri ukonceni apliakce journal nepotrebujes, protoze transakce jsou uzavreny. Kdyz ti ale apliakce spadne, journal zustane na disku. A pri dalsim spusteni udela Sqlite podle toho journalu rollback. A co se asi stane, kdyz ti treba ten dropbox aktivne sesynchronizuje rozdelany journal, ale uz ne jeho dokonceni? To si pak nekde jinde pustis apliakci... uvidi nedodelany journal, a bude se snazit provest rollback na uplne jinymi daty...
Tohle vubec neni haklivost Geogetu, tohle je naprosto obecny problem. Staci si chvili googlovat "database dropbox"...