Puenktlich zur Preisaenderung der Time Capsule 1TB Edition hat mein Router nach knapp 5 Jahren Dienst an vorderster Front seinen Ruhestand angetreten. Nach langen Hin und Her ob ich nun eine aufgebohrte Eigenbauloesung als Wireless Backup Loesung einsetzen soll oder doch eine Time Capsule, ist die Entscheidung am Ende (vorallem aufgrund der Preisaenderung) auf die Time Capsule gefallen.

Wer die Time Machine verwendet (sei es per USB/Firewire oder ueber WLAN in Kombination mit einer Time Capsule) kennt das Problem vielleicht: Nachdem ein Backupvorgang gestartet wurde ist die Time Machine erstmal mehrere Minuten (gerne auch mal Stunden) damit beschaeftigt das Backup vorzubereiten. Eigentlich weiss die Time Machine welche Dateien/Ordner sich seit dem letzten Backup geaendert haben und sichert auch nur diese beim naechsten Backupvorgang. Doch manchmal kann es passieren, dass die Time Machine das ganze nicht mehr zurueckverfolgen kann.

Time Machine kann die Aenderungen an den Dateien/Ordnern nicht mehr zurueckverfolgen, wenn das System nicht richtig heruntergefahren oder ein aktiviertes Laufwerk nicht korrekt ueber die Auswurffunktion entfernt wurde (siehe Apple Support Dokument). Ist das der Fall, muss der Backupdatenbestand mit dem zu sichernden Datenbestand verglichen werden. In der Logdatei (einzusehen mittels Konsole.app) steht dann die Zeile: /System/Library/CoreServices/backupd Node requires deep traversal:/ reason:kFSEDBEventFlagMustScanSubDirs| kFSEDBEventFlagReasonEventDBUntrustable|.

Seit dem Einsatz der Time Capsule habe ich genau dieses Problem, jedes Backup beginnt erstmal mit einem deep traversal und nach 45 Minuten endlosen Wartens steht dann fest, 500 kB oder auchmal mehr muessen wieder auf die Backup-Platte geschrieben werden. Ein weiteres Problem das sich ergeben hat war der Shutdown Prozess. Normalerweise dauert dieser Prozess 5-10sek., seit dem Einsatz der Time Capsule auch mal gut und gerne 2 Minuten, jedoch nur, wenn vorher die Time Machine zum Einsatz kam.

Beim Durchsehen der Logdateien um erste Anhaltpunkte zu erhalten wo der Fehler zu suchen ist, bin ich dann auf den folgenden Eintrag gestossen: kernel Previous Shutdown Cause: 5.Was die erste Vermutung bestaetigte, dass Mac OS X ein offensichtliches Problem beim Shutdown Prozess hat, was somit die Ursache fuer die andauernden deep traversal Backups war. Die Ursache fuer den Shutdown Fehler ist in der Logzeile dir: /Volumes/max.mustermann/.fseventsd getting new uuid: 7A534B21-C2D6-44AE-A617-7F1BD37EE9FC zu suchen, die meiner per MobileMe synchronisierten iDisk bei jedem Systemstart eine neue UUID zuordnet.

Der fseventsd Daemon wird von Spotlight und Time Machine verwendet um ueber Aenderungen auf Dateiebene informiert zu werden. Ich vermute, dass beim Shutdown die iDisk nicht korrekt aus dem System gebunden werden kann und sich daher a.) der Shutdownprozess verlaengert und b.) durch das nicht korrekte Auswerfen der iDisk diese bei jedem Systemstart eine neue UUID erhaelt was bei Time Machine dazu fuehrt das ein deep traversal Scan beim naechsten Backup wieder ansteht um die Datenbestaende zu vergleichen.

Das Stoppen der Synchronisation der iDisk mit MobileMe hat jetzt erstmal den Fehler behoben. Mac OS X hat wieder die gewohnten 10sek. Shutdown Zeiten und Time Machine ist in Verbindung mit der Time Capsule in der Lage innerhalb kuerzester Zeit ein Backup zu erledigen. Warum die iDisk jetzt nicht mit der Time Capsule spielen moechte kann ich an dieser Stelle (noch) nicht sagen. Vielleicht handelt es sich um ein generelles iDisk/Time Machine Problem oder doch nur in Kombination mit der Time Capsule oder ich hab was zerschossen.

Mit dem Release von iPhone OS 3.0 wurde auch das iPhone Configuration Utility einem, und wie ich finde gelungenem, Update auf Version 2.0 unterzogen. Es bietet jetzt nicht nur mehr Einstellungesmoeglichkeiten (bspw. CalDAV, abonnierte Kalender, LDAP, WebClips), sondern auch endlich die Moeglichkeit verschluesselte WLAN Netzwerke von vornherein mit dem passenden Netzwerkschluessel zu versehen. Das war leider vorher nur durch einen kleinen Workaround moeglich, somit ist der Blogartikel obsolete. Das bietet noch einen weiteren Vorteil, da vorher die mobileconfig Datei aufgrund des Workarounds nach der Generierung nochmals angefasst werden musste, war es nicht moeglich diese mit einem Zertifikat zu versehen das die Authentizitaet des Austellers und die Integritaet des Inhalts bestaetigte.

Mit iPhone OS 3.0 ist es seit heute moeglich einen Kalender mittels CalDAV zu abonnieren. Das Ganze funktioniert ueber Einstellungen->Mail, Kontakte, Kalender ->Account hinzufuegen->Andere->Abon. Kalender hinzufuegen. Damit lassen sich nun auch endlich die Geburtstagsabonnements auf das iPhone holen ohne das dafuer bspw. mittels iCalBirthday eine *.ics Datei erstellt werden muss, diese dann in iCal zu importieren um somit mittels MobileMe OTA Synchronisation das Ganze auf dem iPhone zu haben.

Damit die Geburtstage nun mittels Kalenderabonnements ihren Weg auf das iPhone finden, aktiviert man zuerst in iCal den Geburtstagskalender (laesst sich unter iCal->Einstellungen aktivieren). Danach wird der Kalender auf MobileMe veroeffentlicht (siehe Bild) worauf man automatisch ein Benachrichtigung erhaelt unter welcher Adresse der Kalender abonniert werden kann. Diese Informationen kann man sich dann gleich auch noch automatisch per Mail schicken lassen. Die URL aus der Mail per Copy&Paste in Einstellungen->Mail, Kontakte, Kalender ->Account hinzufuegen->Andere->Abon. Kalender hinzufuegen eintragen und das wars dann auch schon.

Die Sache hat auch einen Haken. Der Kalender kann jetzt von jedem der die Adresse kennt ebenfalls abonniert werden. Des Weiteren gibt es damit auch keine akustische oder visuelle Meldungen mehr wer den gerade Geburtstag hat.

Anmerkung: Apple’s Support Dokument schreibt dazu:“While a Birthday calendar may appear in the Subscriptions calendar of iCal, it is not a normal subscription calendar, and cannot be added to your iPhone/iPod touch.”

Seit einigen Monaten unterstuetzt Google Microsoft Exchange. Aus gegebenen Anlass habe ich heute Google Sync auf meinem iPhone eingerichtet, da es mit Google Calendar moeglich ist einen/mehrere Kalender mit einer/mehreren Personen zu teilen. Mein Google Kalendar hat daher einen privaten und einen gemeinsamen Kalender. Der Exchange Zugang war relativ leicht mit der Anleitung von Google aufgesetzt. Nach dem ersten Sync musste ich dann feststellen, dass lediglich der private Kalendar per Exchange synchronisiert wird, alle weiteren Google Kalender bleiben bei der Synchronisation erstmal aussen vor. Auch fuer dieses Problem findet sich bei Google eine Anleitung, doch leider funktioniert diese nicht. Beim Aufruf der Seite http://m.google.com/sync (aus dem mobilen Safari) erscheint die Fehlermeldung, “Geraet wird nicht unterstuetzt”.

Da dies die einzige Moeglichkeit ist (ausser man ist Google App Benutzer mit einer eigenen Domain) die Sync-Eigenschaften einzustellen, muss man sich eines Workarounds behelfen. Klickt man auf den Link Sprache aendern und waehlt als Sprache English, so gelangt man automatisch auf die Google Login Seite. Nach Angabe der geforderten Informationen gelangt man auf die Konfigurationseite der Geraete die over the air mit diesem Account synchronisiert werden. Dort lassen sich dann bis zu 5 Kalender auswaehlen die synchronisiert werden sollen.

Endlich wurde mir das Werbebudget fuer 2009 freigegeben und die ersten Werbetraeger wurden auch schon in der freien Wildbahn gesehen. Aber seht selbst. Mein Dank geht hier nochmal an den anonymen Leser-Reporter der mir das Bild ueber dunkle Kanaele zukommen liess.

Bus Werbung