Rozdílová synchronizace šetří data. OneDrive ji zařazuje do repertoáru

Dosud platilo, že když jste upravili část souboru, musel se do OneDrivu znovu nahrát celý. To se teď mění.

11

Vývojový tým OneDrivu dokončil a vydal jednu zdánlivě malou a neviditelnou, přesto velice důležitou funkci. Cloudová jednotka na tradičních počítačích nově podporuje rozdílovou synchronizaci. Dosud tak uměla pracovat pouze s příslušnými soubory v Office. Díky rozdílové synchronizaci nemusí být do cloudu znovu nahráván celý soubor, pokud se změnila pouze jeho část.

Což v případě malých dokumentů nemusí tolik znamenat, ale čím větší soubor upravujete, tím více změnu pocítíte. Vyhrávají úplně všichni, protože pro servery to může znamenat menší nápor, stejně tak se sníží zátěž vašeho připojení a propojující infrastruktury. Pro člověka je nakonec pravděpodobně nejdůležitější ušetřený čas.

Dokončení funkce bylo oznámeno před několika dny na webu, kde lidé přidávají návrhy na nové funkce a hlasují pro ně. Upozornil na to Omar Shahine z managementu služby, jeho oznámení zaznamenal Mehedi Hassan. O rozdílové synchronizaci Microsoft zřejmě poprvé promluvil už loni na konferenci Ignite. Rozdílová byla dle tehdejšího vyjádření chystána nejen pro OneDrive, ale také pro Teams a SharePoint. Podporována by měla být u souborů až do velikosti 100 GB.

Dle vývojového plánu, který potvrzuje dokončení a vydání rozdílové synchronizace, Microsoft aktuálně distribuuje podmíněný přístup pro klienta pro macOS. V květnu by měla být dokončen přehled doporučených souborů pro práci, to se ale týká jen firemní varianty OneDrivu. Klient pro Android od dubna nabízí tmavý kabát. Rozdílová synchronizace by měla být už dostupná všem.

Zdroj: Feature Suggestions for Microsoft OneDrive via Omar ShahineThurrott.com | Microsoft OneDrive Blog

Rozdílová synchronizace šetří data. OneDrive ji zařazuje do repertoáru
Ohodnoťte tento článek!
5 (100%) 1 hlas/ů

11 KOMENTÁŘE

  1. Moc nerozumím tomu, že dosud tak uměla pracovat jen s příslušnými soubory Office. Přitom Office soubory, tedy takové ty modernější, jako .docx, .xlsx, .pptx jsou ve skutečnosti ZIP archivy, kde stačí jedna malá změna (změnit jedno písmenko) v souboru a změní se celý soubor, takže rozdílová synchronizace je úplně k ničemu.
    Ostatně moc souborů, kde by rozdílová synchronizace měla smysl, mě nenapadá. Možná nějaké velké log soubory, kdy se přidávají informace jen na konec. Tedy asi i u zdrojových kódů to má nějaký smysl, ale kolik lidí programuje tak, aby jejich soubory měly nějakou nezanedbatelnou velikost.

    • Je to jednodušší, než se ti může zdát. Jen o těch dokumentech nemůžeš přemýšlet jen na úrovni konečného produktu (tedy ZIP archivu). Archivy obvykle obsahují množství souborů. A právě Microsoft, který zná své formáty nejvíce dopodrobna, si může dovolit provádět takové rozdílové synchronizace. Uvnitř konečného ZIP archivu najdeš samostatné obrázky, samostatný text a spoustu dalších věcí. Místo celého dokumentu se tedy vezme například pouze ta stránka textu, u níž došlo ke změně, nahraje se na OneDrive a tam proběhne vložení změněné části textu. Díky tomu je možné přenést třeba pouhý kilobyte namísto 10 megabytového dokumentu plného obrázků.

      • Myšlenka hezká, ale dost pochybuju, že by si troufli něco nazývat synchronizací, když to může měnit ten soubor.
        Když vezmu nějaké pptx, zipem ho rozbalí a pak zpátky zabalím, obsahuje tytéž soubory jako původní, jde i normálně otevřít, ale soubor je to evidentně jiný (má jinou velikost). Pokud by mi ho automaticky v rámci synchronizaci měnili na nějakou jejich verzi, asi by mě moc nepotěšili. A to nemusím samozřejmě dělat ručně, stačí tentýž soubor načíst v Libre Office a beze změny ho uložit.
        To by pak mohli v rámci synchronizace přebalovat i jiné archivy nebo optimalizovat png soubory a to opravdu není účelem synchronizačního nástroje.
        Jinak na tom BMP souboru, na kterém to ukazují, tam to bude fungovat bezvadně. Tam opravdu změna jednoho pixelu udělá jen změnu pár bytů. Ale změna jednoho pixelu v JPG, GIF či PNG už změní celý soubor.

        • U ztrátové komprese rozdílová synchronizace/aktualizace/“jakýkoliv správný termín“ opravdu moc nejde. Ale u bezztrátové komprese to v leckterých případech lze. ZIP i PNG jsou bezeztrátové (kompresní) formáty. Když rozbalíš ZIP a znovu zabalíš veškerý obsah, nový archiv už nejspíš nebude mít stejný kontrolní součet, velikost a další parametry. Z mnoha důvodů — jiná míra komprese, jiný algoritmus… Ale je obsah zachován beze změny? Je. Podobně jako můžeš zapsat číslo 2 snad nekonečným množstvím způsobů: 2222-2000-220; 1+1; 2*1; 4/2; nebo zkrátka 2. Nebo použít osmičkovou soustavu nebo šestnáctkovou nebo kteroukoliv jinou. Je to jiné, ale zároveň stejné.

          Jak tedy udělat rozdíl z PNG souborů? Převeď je do BMP — z nich, jak sám říkáš, už rozdíl udělat lze. Pak ho zpětně převeď do PNG. Hashe souhlasit nemusí, ale obrazová data jako taková zůstanou beze změny.

          Do určité míry to jde dělat i s videem. Třeba Transport Stream (*.ts) lze stříhat a lepit skoro jako pásku. Příklad: nahraju film z televize, reklamy odstřihnu, aniž bych musel překódovat celek a tedy ztratit i informace (kvalitu), neboť zde už se jedná o ztrátovou kompresi. Nahraju na cloud úložiště. Druhý den zjistím, že chybí na konci 2 minuty filmu. Tak můžu nahrát konec, až bude v TV opakování, a přilepit k původní nahrávce. Na cloud úložiště pak už místo několika gigabytů mohu nahrát jen několik desítek megabytů.

          Možná, že je to nad rámec běžné synchronizace, možná je pro to jiné pojmenování, ale jsou způsoby, jak něčeho takového docílit.

          • Tohle já naprosto chápu. Chápu, že se neztratí informace v souboru. Ale synchronizační služba přeci nemůže svévolně měnit soubory, byť by obsah zůstal stejný.
            Tedy nezpochybňuju, že to jde. Ano, jde to. Ale je dost divné, kdyby to opravdu One Drive dělal. Pak by se mohlo stát, že člověk dá synchronizovat nějakou složku s aplikací, která si své soubory hlídá pomocí kontrolních součtů nebo jen pomocí velikosti a ejhle, aplikace z čista jasna nepracuje, protože synchronizační program jí změnil soubor?
            Nebo váš lokální zálohovací software porovnává, co má zálohovat a najednou vidí úplně jiný soubor? Nebo porovnáváte dvě složky a oni jsou rozdílné, i když jsou stejné? Nějak si prostě nedokážu představit, že by součást systému modifikovala (netransparentně) soubory. Interně si je samozřejmě může komprimovat jak chce, ale z hlediska uživatele musí ten soubor vypadat pořád na bit stejně.

            • 123456 rozkomprimuju a dostanu ABCDEF.
              Vezmu ABCDEF zkomprimuju to a dostanu 123456.
              Tak hash preci musi vyjit zase stejny.
              Kdyz udelam zmenu na ABCDXF, tak po zkomprimovani dostanu 852963 a tedy i rozdilny hash, ale je tam zmena.

              U Office, kde ma MS cely proces vytvoreni souboru, to myslim nemuze byt problem.
              U obrazku to pujde aplikovat dobre na nekomprimovane BMP a mozna na neztratove komprimovane PNG, ktere ma ty komprese dobre popsane a tak to muze MS byt schopne spojovat stejne jako u tech Office.

            • Redmarx:
              Špatně. Když něco rozkomprimujete a následně opět zkomprimujete, tak stejnou věc dostanete jen tehdy, použil-li jste stejný komprimační algoritmus se stejným nastavením.
              Tedy, když rozkomprimujete třeba .docx, který je interně zazipovaný, tak ho můžete zazipovat tisíci různými způsoby a pokaždé z toho vyleze nějaký jiný .zip soubor. Jen bude mít stejný obsah. Ty jiné způsoby komprimace si nepředstavujte nějak extra složité. Stačí jiné pořadí komprimovaných souborů, jinak velký slovník atd.
              U MS Office samozřejmě nemá Microsoft celý proces pod kontrolou, protože jejich formáty jsou otevřené, tedy může s nimi pracovat kterýkoliv jiný program, a ten zcela logicky může tu ZIP kompresi provést trochu jinak.
              Jinak u PNG je právě krásně vidět, kolika možnými způsoby lze jeden obrázek zakódovat. Já používám prográmek optipng, který zkouší až několik stovek nastavení komprese a hledá, při kterém je ten obrázek nejmenší a tu pak teprve použije.

            • Proto si tak říkám (možná je to šílenost, tak to berte s rezervou), zda by se nemělo začít více nahlížet „pod pokličku“, čili neposuzovat výhradně obal, ale i obsah. V současné době je stále jedním z hlavních znaků jakési důvěryhodnosti nebo ekvivalence to, zda mají zkoumané soubory stejný hash. Je mi jasné, že u řady souborů to může být těžko uchopitelné, ale už dnes obvykle archivy obsahuji (ač je to nepovinné) kontrolní součty všech obsažených souborů. Pokud by se vytvořil ještě hash celého tohoto indexu (mínus nějaká metadata v případě dokumentů), mohl by se porovnávat tento. Pak bychom hned věděli — ano, archiv byl přebalen, ale do obsahu nebylo zasahováno. Dokument stačí jen znovu uložit beze změny, na stejném PC a ve stejném SW a změní se hash dokumentu. Protože se uloží, kdy a kým byl dokument naposledy uložen. Ale měli bychom takový dokument automaticky zavrhnout?

            • Ano, pokud nesedi hash celeho souboru, tak pro me nemuze byt duveryhodny a proto ho musim zavrhnout.
              Nevedel jsem, jak to tam probiha, prilis docx neresim, pokud je to tak, jak pise Radek, tak se stane cely OneDrive neduveryhodny, ikdyz on z podstaty veci neduveryhodny je, tak spis nepouzitelny, to je asi spravne slovo k tomu, jak ten MS nesmysl nazvat.

  2. Jinak teda ja si na OneDrive zalohuju z mobilu, a to jednocestne.
    Vysvetlim: udelam nekde v prirode fotku do mobilu, odeslu ji na OneDrive. Vratim se domu a fotku z mobilu zkopiruju do PC a zazalohuju na sve uloziste.
    Jinymi slovy, kdyby se mi stalo s mobilem neco mezi prirodou a domovem, tak o fotku neprijdu, asi bude mit jiny hash, ale je na OneDrive. Doma ale uz pracuju s originalem.

    • Tak pokud v té OneDrive aplikaci nenastavíš, aby se fotky nahrávaly v menším rozlišení (nevím, jestli takovou funkci OneDrive má, ale obvykle to jde vypnout), tak bys na něm měl mít originály.