Fórumok
Üdv!
Adott két gép, amiken szinkronizálva van ugyanaz a méretes könyvtárstruktúra, rengeteg fájllal. Azonban az egyik gépen ez a struktúra jelentősen megváltozott, sok fájl át lett mozgatva más könyvtárakba, új könyvtárak lettek létrehozva. (Pár fájl módosítva vagy törölve lett, de ez a teljes könyvtárstruktúra méretéhez képest elenyésző változás.) A kérdés az, hogy van-e valamilyen kész megoldás arra (lehetőleg windowsra), hogy úgy szinkronizáljam a két gépen ezt a könyvtárstruktúrát, hogy a nem változtatott, csak mozgatott fájlok ne legyenek újra átküldve a hálózaton?
Persze le tudnám programozni, de biztos vagyok benne, hogy más már megírta, csak nem volt szerencsém a google-lel.
Hozzászólások
sub
SyncToy 2.1
http://www.microsoft.com/en-us/download/details.aspx?id=15155
--
maszili
Elsőre biztató volt, mivel ismeri a rename operationt is, de mint kiderült, fájlmozgatásra ezt már nem alkalmazza.
*: A biztonság kedvéért elsőre nem akartam, hogy töröljön is, gondoltam ha látom hogy jó, akkor majd átállítom vagy beállítom újra.
Tehát több, mint 9 gigányi adatot másolna így át, egy 54Mbps-os wifi kapcsolaton. Végül is pár óra alatt megvan...
Végül nem futtattam le semmilyen hagyományos szinkronizáló programot, noha ennyi idő alatt már sokszor lefutott volna. Inkább elkezdtem lekódolni powershellben, mert elkezdett érdekelni a probléma. Az első verzió hamar elkészült, az alapelv az volt, hogy különböző metaadatok (fájlnév, utolsó módosítás dátuma) megkeresem az egyező fájlokat, ha jó helyen van semmit nem csinálok, ha rossz helyen van átmozgatom a helyére, és csak akkor másolom át ha nem létezik a távoli oldalon. Csakhogy nem gondoltam arra, mi a helyzet a duplikátumokkal, amik hatására természetesen a script mindenféle hülyeséget csinált az ilyen esetekben.
Ezután pihentettem pár napig a dolgot, végül kigondoltam mit kell tenni. Csoportosítani kell a fájlokat a fenti metaadatok szerint, ekkor az azonos fájlok egy csoportba kerülnek. Amikor egyezőséget keresünk, akkor a csoportok metaadatait kell összehasonlítani. Ezután ha nem találtunk a távoli oldalon csoportot, át kell másolni a fájlt a helyi oldalról. Ha találtunk, és a távoli csoportban van olyan fájl, ami jó helyen van, nem kell tenni semmit. Ha nincs, akkor a távoli csoportban kell keresni olyan fájlt, ami a helyi csoportban nincs az adott helyen, azt át lehet mozgatni. Ha ilyen sincs, a távoli csoport egyik fájlját kell másolni a megfelelő helyre. Megírtam a scriptet, de végül nem futtattam le. Ugyanis kiderült, hogy a módszer bár működik, de iszonyatosan lassú. Sokkal lassabb, mintha az egész könyvtárt másolnám át, úgy ahogy van. Gondolom a hatalmas fájllistában való keresés viszi el az idő nagy részét. Talán át lehetne írni úgy, hogy végül quick search-t használjon, vagy egy ciklussal egyszerre járnám be a két listát (lásd sort merge join), de más ötletem van.
Ugyanis idő közben ismertem meg a compare-object cmdlet-et, amit ha megfelelően fel tudnék paraméterezni, a munka nagy részét el is végezné, remélhetőleg sokkal hatékonyabban, mint amit én akármilyen trükközéssel össze tudok hozni. Úgyhogy a terv az, hogy a harmadik verzió compare-object-et fog használni.
Ez a "compare-object" is a powershell része?
Miért lassú a metaadatok nyálazása? Exponenciálisan elfut az összehasonlítások száma?
Ugye 1 irányú szinkről van szó?
Azon gondolkodok, hogy ha a meta adatok szerint rendezed a fájlokat (amúgy is végig kell menni minden fájl meta adatán legalább egyszer), akkor a fenti gondolatmeneted első része kellene hogy működjön szerintem.
Tehát a meta adat 3 részből állna. 2 rész: fájl méret és utolsó módosítás dátuma, a harmadik pedig vagy név, vagy pedig checksum. Ez utóbbi jobb lenne, nem tudom elérhető-e windows-on.
Ha ez meg van, akkor nem értem hogy miért lenne lassú.
Ha mindkét oldalon megcsinálnád a listát, majd pl. egymásba merge-eled, de úgy, mintha minden meta adatra (az összes elemére) egy hash-t generálnál, majd a 2 listát egyetlen változóba tolod, majd ezt sorba rendezed. Meg kell jegyeztetni még soronként a path-t és hogy helyi vagy távoli-e. Elsődlegesen meta adat, másodlagosan path alapján kell rendezni.
Ekkor az egyforma hash-ek egymás mellett lesznek. Így sorba kell menni a lista egyforma tagjain, melyek egymás mellett lesznek. Ezek után vizsgálnád a path-t. Ha jól gondolom, akkor a következő lehetőségek lesznek:
1) meta adatok egyeznek + path is egyezik -> nincs tennivaló
2) meta adatok egyeznek + path nem egyezik (itt ez azt jelenti, hogy habár művelet kellhet, de mivel van ilyen metaadattal fájl a távoli gépen, ezért mindenképp csak a távoli gépen hajtjuk végre a műveletet az ottani fájllal a hálózati átvitelt megspórolva):
2-a) helyi path-al nincs távoli fájl és távoli path-al nincs helyi fájl -> fájl mozgatása távoli path-ról helyi path-ba a távoli gépen
2-b) helyi path-al nincs fájl a távoli gépen -> a távoli path-ról másoljuk a fájlt a helyi path-ra a távoli gépen
2-c) távoli path-al nincs fájl a helyi path-on, akkor fájl törlése a fenti műveletek után
3) nincs távoli meta adat a helyin, ekkor távoli törlése
4) nincs helyi meta adat a távolin, ekkor helyi másolása a távolra
Ugye a fentieknél ha egy állítás igaz volt és végeztünk műveletet, akkor tovább nem vizsgáljuk a többi feltételt (1-4-ig).
"Ez a "compare-object" is a powershell része?"
Igen, PowerShell 2.0 óta. Lényegében egy diff-et valósít meg objektumok listáin, de szépen lehet okosítani, hogy milyen propertyket vizsgáljon, mekkora legyen a slide window (ha kell), stb.
"Miért lassú a metaadatok nyálazása? Exponenciálisan elfut az összehasonlítások száma?"
Ha n a helyi oldal csoportjainak száma és m a távoli oldal csoportjainak száma, akkor n*m az összes összehasonlítás száma. Mivel a távoli oldal csoportját egy egyszerű where-object-tel keresem, az pedig lineáris keresést valósít meg. Ráadásul most jutott eszembe, hogy akkor is tovább keres, ha már megvan a keresett csoport, ezen egy "|select-object -first 1" elvileg segítene, de még így is n*m/2 összehasonlítás történne. Tehát nem a metaadatok lekérése vagy összehasonlítása lassú, egyszerűen rossz a kereső algoritmus, amit egyébként egyszerű lenne javítani, pl. amit te leírtál (és amire már én is utaltam).
"Ugye 1 irányú szinkről van szó?"
Igen.
Ez nem jó?
:)
Jól hangzik, meglesem, köszi!
Szerk: hát, több probléma is van.
Az első ez:
Namost a "file creation time" azért nem lesz jó, mert vannak olyan megváltoztatott fájlok, amiknek ez az attribútuma nem változott, csak a "file modification time".
A másik ez:
Arról nem ír, hogy a fastcheck opció erre az esetre alkalmazható-e (gyanítom azért, hogy igen).
Gondoltam trükközzünk, szépen felcsatoltam a megfelelő könyvtárat egy hálózati meghajtóként, gondoltam akkor majd azt hiszi lokálisan érhető el. Egy fenét, egy szép errorral honorálta:
Persze ugyanez történik akkor is, ha a fent leírt //host/share módon adom meg az útvonalat.
Amit még nem próbáltam, hogy a másik gépen elindíthatnám a szervert, és akkor socketen talán menne. De kezdem úgy érezni, hogy ezt a szoftvert nem windows-windows szinkronizációra találták ki.
A ráadás az, hogy jó lenne egy olyan opció, ami csak logolja, hogy mit tenne, de valójában nem tesz semmit. Így láthatnám, hogy egyáltalán úgy működik-e ahogy azt szeretném.
A
nem oldja meg?
Itt nem pont azt írja, hogy mindenképpen áthúzza az összes adatot? Innentől kezdve neked semmiképpen nem jobb így, mint bármilyen eddigi megoldás. Valamilyen más módon kell biztosítanod a kiszolgálást.
Szerintem a grafikus felületű cucc részben vagy egészben mutatja, mit akar csinálni.
:)
+1 Unison
Használom élesben, megfelelően működik több gép között is.
Csaba
Ez vajon Windowsra is hatékony? Milyen protokollon keresztül folyik a távoli művelet? Sima SMB? És hatékony olyan szempontból is, hogy ha lehet a távolin mozgatni adatokat, akkor onnét mozgatja és nem másolja át a fájlt a helyiről?
Az eredeti poszt írásakor elkezdtem én is gondolkodni, mert érdekelt a probléma, és bár nem programoztam le, a működés a következő lenne:
Egy file-t az md5 hash + filehossz (ID) azonosítson. Ekkor:
1) mindkét gépen állítsuk elő az összes file-ra az ID-ket (de ne hálózaton keresztül:))
2) másoljuk a célgépre a hiányzó fileokat egy pool-ba (pl. a forrásgépen tarolva/a célgépen kitarolva, esetleg az eredeti filenevek helyett ID-t használva)
3) a célgépen a pool-ból, és a régi könyvtárstruktúrában lévő fileokból gazdálkodva építsük fel az új könyvtárstruktúrát; ha két file-nak ugyanaz az ID-je, akkor lehet másolni/linkelni, különben csak mozgatni kell
Kicsit késő, illetve nem tudom mennyire jó válasz a késésedre, úgyhogy csak a későbbi keresgélők életét megkönnyítendő írok.
Én a FreeFileSynch -et használom szinkronizálásra. Nem tudom van e elég esze ahhoz, hogy az átmozgatott fájlokat felismerje és nem másolja újra, de egyébként jó kis eszköz.
Esetleg még a link shell extension jöhet szóba. Különösen a smart mirror opciója lehet érdekes. Azért megjegyzem, én csak sima linkelésre használom.
Szerk:
ezek szerint a Free File Synch tudja kezelni az átnevezett és mozgatott fájlokat is.