Vor einiger Zeit ist Google Drive erschienen. Das ist sowas wie Dropbox. Eigentlich erstaunlich hat Google, die ja sonst für innovative Dienste bekannt sind, quasi die Mutter aller Cloud-Dienste erst so spät eingeführt.
Als reger Google-Dienste Nutzer habe ich also von Dropbox auf Drive umgestellt. Das ging nicht ganz problemlos.
Ich verstehe bei diesen Diensten nach wie vor nicht, warum man nicht selbst angeben kann welche Ordner synchronisiert werden sollen. Der Root Ordner ist immer vorgegeben. Ich will aber nicht unbedingt, dass meine Daten lokal in einem Ordner „Google Drive“ landen. Dank der Bibliotheksfunktion von Windows 7 kann man das aber etwas abfangen.
Um den Wechsel zu vollziehen, musste ich also alle Daten vom Dropbox Ordner in den Google Drive Ordner verschieben. Dass ich damit einen wahnsinnigen Netzwerktraffic auslöse, war mir schon klar. Ging aber problemlos. Dachte ich jedenfalls.
Plötzlich fallen mir Ordner auf die ein „(1)“ angehängt haben. Bei Windows immer der Hinweis auf einen doppelten Ordner. Tatsächlich gibt es in Google Drive diese Ordner doppelt, drei oder vierfach, allerdings ohne das „(1)“ dahinter. Warum diese erstellt wurden, ist mir unklar. Sie sind alle leer. Also habe ich sie einfach gelöscht. Sie sind auch nicht wieder erschienen.
Ich verwende als Ersatz für den Windows Explorer den Freecommander. Hier taucht das nächste Problem auf; der Google Drive Ordner wird nicht angezeigt. Ich kann ihn durch manuelle Eingabe zwar erreichen und alle Unterordner werden angezeigt, nicht aber der Hauptordner.
Durch etwas nachforschen habe ich bemerkt dass der Ordner mit dem Attribut „System“ versehen ist. Er wird also als Systemdatei markiert. Der Freecommander ist so eingestellt, dass er diese Dateien nicht anzeigt. Der Windows Explorer wäre eigentlich auch so eingestellt, der Ordner wird aber trotzdem angezeigt. Warum, ist mir nicht klar.
Die Lösung scheint einfach: das Attribut entfernen. Das ist aber einfacher geschrieben als getan!
Unter Windows 7 kann man nicht einfach die Eigenschaften aufrufen und das Attribut entfernen, es wird für Ordner gar nicht angezeigt. Nun, dann machen wir es halt über die Kommandozeile, der Befehlt lautet „attrib -s [Ordnername]“. Fehler, geht nicht. Durch erneutes rumprobieren dann festgestellt dass es mit dem langen Namen nicht klappt (warum auch immer), man muss den Kurznamen verwenden (findet man mit „dir /a /x“ raus). Das System-Attribut ist nun weg und siehe da, der Ordner wird auch im Freecommander angezeigt. Problem gelöst? Mitnichten!
Leider wird das Attribut durch den Client bei jedem Neustart neu gesetzt. Aaargh! Wer kommt nur auf eine solche Idee!
Meine Lösung ist ein kleines Skript das ich halt nach dem Systemstart starte und welches das Attribut entfernt. Der Client selbst wird ja normalerweise nicht neu gestartet.
Ich habe auch kurz getestet ob der Trick mit den symbolischen Links bei Google Drive funktioniert. Das scheint nicht der Fall zu sein, der Ordner wird zwar mit einem Synchronisations-Symbol ausgestattet aber der Sync. Vorgang startet nicht. In Google Drive kommen weder der Ordner noch die Dateien darin an.
Da muss Google noch mal ran. Ansonsten funktioniert aber Google Drive gut. Die Verknüpfung mit den anderen Diensten ist natürlich ganz praktisch. Und dank der API werden wohl noch ein paar praktische Funktionen hinzukommen.
Update 10.05.12:
Nachdem heute morgen auch noch eine kryptische Fehlermeldung erschienen ist, die behauptet hat, dass meine Harddisk (physisch) fehlt, habe ich den Schlussstrich gezogen. Dropbox drauf und Daten verschoben. Google Drive weg (sorry). Dank Symlinks sind die Daten nun auch da wo ich sie eigentlich haben will. Bei der Gelegenheit auch noch festgestellt dass Dropbox wohl so eine Art Cache hat. Obwohl ich die Daten gelöscht hatte, wurden ca. 1000 MB in etwa 10 Sekunden hochgeladen. So schnell kann mein Upload unmöglich sein…