Jag använder Unison för att synkronisera filer mellan datorer. Det är ett utmärkt verktyg. Fram till nyligen har det inte gått att synkronisera filer mellan olika plattformar på ett enkelt sätt - om man använder svenska tecken. Eller rättare sagt, exotiska tecken som manualen säger, allt utom 7-bits ascii. Sålänge man håller sig till en och samma plattform har det inte varit några problem.
Nu finns en lösning - senaste versionen av unison fungerar utmärkt oberoende av teckenkodning. Jag har fått synkronisering att fungera mellan Mac OS X, Windows och Linux (Debian, Ubuntu) smärtfritt. Jag använder en Debianbaserad linuxserver som "nav" och de övriga maskinerna synkronisera mot den.
Tricket för att få det att fungera är att köra en tillräckligt sen version av unison på alla ställen. Klientens version måste fungera med den version som ligger på servern. Viktigt är att man kan ha flera samtidiga versioner på servern. Detta gör att man kan ha en blandning av olika versioner, utan problem.
En liten kommentar: i texten säger jag att "det inte behövs" osv. Eftersom en del operativsystem är konfigurerbara i all oändlighet är det inte nödvändigtvis sant. Däremot är det sant för den konfiguration som gäller för standardinstallationer.
Här kommer receptet som fungerar för mig:
På servern (Debian Lenny linux):
---------------------------------
Installera unison med apt-get install unison. Det ger version 2.27.57 för mig:
$unison -version
unison version 2.27.57
Detta räcker utmärkt för att synkronisera andra maskiner med samma version, OM DU HAR SAMMA TECKENKODNING. Kör du t ex ubuntu eller debian behövs inget mer göras. Det behövs däremot om du ska köra Mac OS X eller windows som klienter mot servern. Och det ska vi, inte sant!
Nu checkar jag ut version 2.39.6 från unisons repositorie (funkar troligtvis med andra versioner, om du vill ha exakt som jag så lägg till -r403 till kommandot nedan för att få revision 403)
$mkdir -p $HOME/code/thirdparty
$cd $HOME/code/thirdparty
$svn co -r403 https://webdav.seas.upenn.edu/svn/unison/trunk unison
Du måste ha subversion och ocaml installerat. (På min arkitektur (arm) råkar ocamlopt inte finnas, därför använder jag NATIVE=false. Lämna ut det om du inte behöver det)
$cd $HOME/code/thirdparty/unison
$make NATIVE=false
när kompileringen lyckas kör jag
$ $HOME/code/thirdparty/unison/src/unison -version
och får svaret
unison version 2.39.6
vilket betyder att allt är som det ska.
På Mac OS X (som klient)
---------------------------------
På mac gör jag ungefär likadant som på servern. Detta eftersom de färdigbyggda paket för unison (.dmg) inte var tillräckligt aktuella för att det skulle fungera för mig.
Nu ser jag att det dykt upp en 2.40 för Mac, kan vara värt att prova först!
Annars bygger man såhär. Man behöver förmodligen ha installerat utvecklarverktygen på mac för att det ska fungera. (Du behöver make, ssh, subversion, ocaml och möjligtvis fler saker)
$mkdir -p $HOME/code/thirdparty
$cd $HOME/code/thirdparty
$svn co -r403 https://webdav.seas.upenn.edu/svn/unison/trunk unison
$cd $HOME/code/thirdparty/unison
$make
Om allt gick bra har du nu ett fungerande unison. Det ligger i $HOME/code/thirdparty/unison/src/uimacnew/build/Default/
Jag drog mitt till dockningslisten och så funkade allt som tänkt.
Sist men nästan viktigast: peka ut sökvägen till unison på servern i konfigurationsfilen. Konfigurationsfilen ligger i
~/Library/Application Support/Unison/*.prf på mac os x.
Se till att den innehåller raden
servercmd=XXXX/code/thirdparty/unison/src/unison
där XXXX matchar $HOME på servern. Kör $echo $HOME på servern om du inte vet vad det är.
På Windows (som klient)
--------------------------------
På windows fick jag en av de förbyggda programmen att fungera. Här visar sig verkligen styrkan i att köra en distribution och inte bara ett operativsystem - bibliotek, sökvägar, binärer finns enkelt tillgängliga. På Debian kör jag apt-get install unison-gtk och är sedan klar. I windows är man tvungen att installera inte bara unison utan även ssh (via cygwin är lättast) och gtk. Det tog mig säkert en timme att få att fungera.
Du behöver en tillräckligt sen unisonversion för att få det att fungera mot unison som används på servern.
Instruktioner för hur man gör finns när man letar sig fram till downloads för windows på unisons hemsida. Man behöver unisonbinären, gtk-runtime och cygwin. Jag kopierade bara in unisonbinären rakt in i det uppackade gtk-runtime-biblioteket och det fungerade för mig.
Precis som på mac os x behöver du peka ut sökvägen till unison på servern. Profilen redigeras i unisons grafiska gränssnitt. Lägg till servercmd enligt instruktionerna för mac os x.
Om du följt instruktionerna och bett tillräckligt till datorguden kan du nu synkronisera filer utan problem med teckenkodning!
Tidigare inlägg i ämnet: http://paulsundvall.blogspot.com/2009/10/unison-unicode-och-kompatibilitetsprobl.html
Tack till Albin som tipsade mig om att unison uppdaterats!
Visar inlägg med etikett utf-8. Visa alla inlägg
Visar inlägg med etikett utf-8. Visa alla inlägg
lördag 27 februari 2010
torsdag 12 november 2009
Problem med utf-8 lösta!
Jag har haft en del problem med att få synkronisering av filer på mac os x att fungera. Detta på grund av mac os x val av normaliseringsform för unicode. (läs tidigare inlägg här och här samt här)
Mitt problem är alltså att jag vill kunna synkronisera filer som finns på en filserver, lagrad med utf-8 till en mac. Efter att jag jobbat med filerna antingen lokalt på macen eller de uppdaterats på servern ska jag kunna synkronisera och lösa konflikter. För detta är unison utmärkt, men det fungerar ej för mig eftersom mac os x använder en annan normaliseringsform för unicode, vilket unison ej stöder.
Nu har jag löst problemet
Jag kör en virtualiserad filserver inuti macen. Inne i den virtuella maskinen kan jag köra unison. För att komma åt filerna exporterar jag dom med samba över smb. På macen monterar jag sedan den utdelade mappen och använder från macen. Detta fungerar klockrent. Därtill är krypteringen löst eftersom jag satt upp en krypterad disk inuti filservern.
Receptet ser ut såhär:
Denna lösning har fördelen att jag har en extra utvecklingsmiljö på macen. Virtualisering är en ball grej!
Mitt problem är alltså att jag vill kunna synkronisera filer som finns på en filserver, lagrad med utf-8 till en mac. Efter att jag jobbat med filerna antingen lokalt på macen eller de uppdaterats på servern ska jag kunna synkronisera och lösa konflikter. För detta är unison utmärkt, men det fungerar ej för mig eftersom mac os x använder en annan normaliseringsform för unicode, vilket unison ej stöder.
Nu har jag löst problemet
- inte på ett smart sätt (med lokal fusemontering på macen)
- inte på det rätta sättet (fixa unison, för svårt)
- inte på ett halvsnyggt sätt (synkronisering över sftp, cyberducks synkronisering fungerade inte tillräckligt snabbt och smärtfritt)
- inte på det trekvartssnygga sättet (montering med fuse och iconv (eller ekvivalent) inuti servern, föll på att olika normaliseringsformer inte verkar stödas av iconv i äldre versioner)
- inte på det grova sättet (dubbelriktad rsync scriptat i bash. blev för otillförlitligt och hanterade inte interna länkar korrekt. däremot stöder nya versioner av rsync macs teckenkodning!)
- inte på det alternativa sättet (montera filerna över afp följd av lokal unison, föll på att jag inte fick till det enligt standardreceptet, fråga mig inte varför.)
- inte på det drastiska sättet (tagit bort alla icke-ascii-tecken från alla filer:-)
- inte på det desperata sättet (installera ubuntu på macen, native. det gick iofs bra men det känns fel att inte dra nytta av de grejer som faktiskt är bra med macen, såsom den fantastiska musplattan, mail etc.)
Jag kör en virtualiserad filserver inuti macen. Inne i den virtuella maskinen kan jag köra unison. För att komma åt filerna exporterar jag dom med samba över smb. På macen monterar jag sedan den utdelade mappen och använder från macen. Detta fungerar klockrent. Därtill är krypteringen löst eftersom jag satt upp en krypterad disk inuti filservern.
Receptet ser ut såhär:
- installera virtualbox på värden (mac os x)
- installera gästen (ubuntu 9.10) enligt receptet på virtualbox dokumentationssidor. inga konstigheter alls.
- skapa en extra virtuell disk i virtualbox. Denna hamnar i mac os x som en fil med ändelsen .vdi. Denna lägger jag på valfritt ställe. Den behöver ej vara på ett krypterat filsystem, eftersom innehållet i filen senare kommer att vara krypterat. Justera inställningarna i virtualbox så att gästen når denna extra disk.
- i virtualbox, konfigurera nätverket så att både nat och lokalt nätverk finns (två nätverkskort alltså). Det gör att man kommer åt internet på ett lätt sätt inifrån gästen, samtidigt som man kommer åt sambaservern från mac os x)
- Inifrån gästen (ubuntu), sätt upp den extra disken som ett krypterat filsystem. sök på ubuntu encrypted filesystem för diverse alternativ hur man kan göra.
- inifrån gästen, installera samba och konfigurera den så att hemkatalogerna exporteras.
- sätt ett lösenord på exporten
- varje gång jag vill komma åt filerna startar jag värden, anger lösenordet för filsystemet och låter det boota klart.
- Därefter monterar jag hemkatalogen med smb inifrån finder i mac os x.
- Nu kan jag arbeta i filträdet i mac os x, eller inifrån värden om jag så vill.
- med unison inifrån gästen (måste installeras separat) kan jag synkronisera med filservern.
Denna lösning har fördelen att jag har en extra utvecklingsmiljö på macen. Virtualisering är en ball grej!
söndag 11 oktober 2009
Små, små framsteg med utf-8
Jag har försökt att lösa mina filsynkroniseringsproblem på macen.
Spår 1: afp via netatalk. (tack för tips, anders j!)
Gick inte, fick autentiseringsfel. Bort med leopards regel om krypterat lösenord, funkar ej (trots två omstarter). Väldigt intressant kombo-binärt/text-format apple använder, skumt.
Nytt försök. omkompilering av netatalk enligt standardreceptet. funkar ej heller. Får fortfarande det irriterande "error -5002" från macen. Gaaahh!! Svårt att felsöka en dialogruta från operativsystemet. (5002 är alltså att lösenord i klartext inte stöds)
Spår 2: loopbackmontering med fuse+unison.
Det förinstallerade fuse är för gammalt och stöder inte modulen iconv. In med det nya, tar mig förbi den skumma modulsyntaxen och får monteringen att funka med
./loopback ~/otherhosts/voltaire-as-utf8 -omodules=iconv:subdir,subdir=$HOME/otherhosts/voltaire,from_code=UTF-8-MAC,to_code=UTF-8
efter att jag passerat det irriterande felet att _iconv_open() inte hittats av dynlib.
Spår 2 verkade funka ända till dess att unison klagar på att mina kataloger innehåller filer som är lika bortsett från stora/små bokstäver. Detta trots att jag formaterat om volymen till case insensitive via macs diskverktyg. suck.
Debian-Mac 1-0, igen.
Spår 1: afp via netatalk. (tack för tips, anders j!)
Gick inte, fick autentiseringsfel. Bort med leopards regel om krypterat lösenord, funkar ej (trots två omstarter). Väldigt intressant kombo-binärt/text-format apple använder, skumt.
Nytt försök. omkompilering av netatalk enligt standardreceptet. funkar ej heller. Får fortfarande det irriterande "error -5002" från macen. Gaaahh!! Svårt att felsöka en dialogruta från operativsystemet. (5002 är alltså att lösenord i klartext inte stöds)
Spår 2: loopbackmontering med fuse+unison.
Det förinstallerade fuse är för gammalt och stöder inte modulen iconv. In med det nya, tar mig förbi den skumma modulsyntaxen och får monteringen att funka med
./loopback ~/otherhosts/voltaire-as-utf8 -omodules=iconv:subdir,subdir=$HOME/otherhosts/voltaire,from_code=UTF-8-MAC,to_code=UTF-8
efter att jag passerat det irriterande felet att _iconv_open() inte hittats av dynlib.
Spår 2 verkade funka ända till dess att unison klagar på att mina kataloger innehåller filer som är lika bortsett från stora/små bokstäver. Detta trots att jag formaterat om volymen till case insensitive via macs diskverktyg. suck.
Debian-Mac 1-0, igen.
lördag 3 oktober 2009
Unison, unicode och kompatibilitetsproblem
Jag har försökt att få synkroniseringsprogrammet unison att fungera i mac os x.
Min server använder utf-8 som teckenkodning på filsystemet. Vad mac använder verkar vara normaliserad utf-8 (se här för intressant läsning).
Unison funkar inte alls särskilt bra för mig på sökvägar som innehåller icke-ascii-tecken. En katalog som heter "företag" dupliceras till originalet och en kopia som renderas likadant med en annorlunda representation. Dvs filnamnet är binärt olika men bokstäverna är samma. Det är just detta som unicode-normalisering strävar efter att lösa.
Först trodde jag att det är unison som är boven i dramat, men det är snarare Apples fel! Citerat ur manualsidan för convmv:
Nog med inledning, detta fick mig att läsa på lite om unicode.
Jag använder mitt katalognamn "företag" som exempel.
Det kodas i utf-8 som
66 c3 b6 72 65 74 61 67
ö-et blir alltså hex c3-b6 eller binärt 11000011 10110110 där jag markerat utf-8-prefixen med fetstil. Payload är alltså 11 konkatenerat med 110110 villket är F6 hex som är "direktformen" för ö, eller "Latin Small Letter O with diaeresis" som det heter. Låter snarare som en sjukdom....
Om jag nu kollar vad som hänt på servern ser jag att det finns två mappar som heter företag.
$ls |grep retag
företag
företag
en undersökning av representationen (genom att pipa till hexdump -C) ger (jag har tagit bort newline 0a manuellt):
66 6f cc 88 72 65 74 61 67
66 c3 b6 72 65 74 61 67
ö-et kodas alltså som 6f cc 88 i det första fallet och c3 b6 i det andra (som jag förväntat mig.)
En avkodning enligt ovan ger att 6f är bokstaven o, och prickarna kommer till i efterhand genom cc 88 som binärt är 11001100 10001000 och lasten därmed 0x308 som betyder två prickar(leta efter rad med 0300 i vänstra kolumnen och kolumn med huvud "8").
Det som behövs för att unison ska förstå att dessa två filnamn egentligen är samma är normalisering.
Det är verkligen inte trivialt att hantera teckenkodning korrekt!
Min server använder utf-8 som teckenkodning på filsystemet. Vad mac använder verkar vara normaliserad utf-8 (se här för intressant läsning).
Unison funkar inte alls särskilt bra för mig på sökvägar som innehåller icke-ascii-tecken. En katalog som heter "företag" dupliceras till originalet och en kopia som renderas likadant med en annorlunda representation. Dvs filnamnet är binärt olika men bokstäverna är samma. Det är just detta som unicode-normalisering strävar efter att lösa.
Först trodde jag att det är unison som är boven i dramat, men det är snarare Apples fel! Citerat ur manualsidan för convmv:
Filesystem issues
Almost all POSIX filesystems do not care about how filenames are encoded, here are some exceptions:
HFS+ on OS X / Darwin
Linux and (most?) other Unix-like operating systems use the so called normalization form C (NFC) for its UTF-8 encoding by default
but do not enforce this. Darwin, the base of the Macintosh OS enforces normalization form D (NFD), where a few characters are
encoded in a different way. On OS X it’s not possible to create NFC UTF-8 filenames because this is prevented at filesystem layer.
On HFS+ filenames are internally stored in UTF-16 and when converted back to UTF-8, for the underlying BSD system to be handable,
NFD is created. See http://developer.apple.com/qa/qa2001/qa1173.html for defails. I think it was a very bad idea and breaks many
things under OS X which expect a normal POSIX conforming system. Anywhere else convmv is able to convert files from NFC to NFD or
vice versa which makes interoperability with such systems a lot easier.
Nog med inledning, detta fick mig att läsa på lite om unicode.
Jag använder mitt katalognamn "företag" som exempel.
Det kodas i utf-8 som
66 c3 b6 72 65 74 61 67
ö-et blir alltså hex c3-b6 eller binärt 11000011 10110110 där jag markerat utf-8-prefixen med fetstil. Payload är alltså 11 konkatenerat med 110110 villket är F6 hex som är "direktformen" för ö, eller "Latin Small Letter O with diaeresis" som det heter. Låter snarare som en sjukdom....
Om jag nu kollar vad som hänt på servern ser jag att det finns två mappar som heter företag.
$ls |grep retag
företag
företag
en undersökning av representationen (genom att pipa till hexdump -C) ger (jag har tagit bort newline 0a manuellt):
66 6f cc 88 72 65 74 61 67
66 c3 b6 72 65 74 61 67
ö-et kodas alltså som 6f cc 88 i det första fallet och c3 b6 i det andra (som jag förväntat mig.)
En avkodning enligt ovan ger att 6f är bokstaven o, och prickarna kommer till i efterhand genom cc 88 som binärt är 11001100 10001000 och lasten därmed 0x308 som betyder två prickar(leta efter rad med 0300 i vänstra kolumnen och kolumn med huvud "8").
Det som behövs för att unison ska förstå att dessa två filnamn egentligen är samma är normalisering.
Det är verkligen inte trivialt att hantera teckenkodning korrekt!
Prenumerera på:
Inlägg (Atom)