Des Rechners neue Kleider: Heimgesucht von Geistern
- Ersteller mj
- Erstellt am
mj
Technische Administration, Dinosaurier, ,
<div class="newsfloatleft"><img src="http://www.planet3dnow.de/photoplog/file.php?n=7306&w=s" border="0" alt="Tux"></div>Die Krux eines Exoten ist sein Exotenstatus. Und versucht man zwei Exoten miteinander zu verbinden, geht dies nicht selten schief.
Doch zunächst galt es, den Desktop erneut von Anfang an einzurichten, diesmal mit der 32-bit Version von openSUSE, und die gleichen Probleme, die auch schon mit der 64-bit Version aufgetreten waren, zeigten auch diesmal wieder ihre hässliche Fratze: Der nicht mehr funktionierende X-Server nach der Installation von fglrx zum Beispiel, oder die kaputten Sessions tty1-tty6 bei Verwendung des fglrx-Treibers. Doch auch mit der 32-bit Version von Open Office und openSUSE schlug die Installation des Duden Korrektors fehl, diesmal allerdings mit einer nichtssagenden Fehlermeldung. Offenbar ist die Version von OpenOffice.org, die in den openSUSE Repositories feilgeboten wird, in etlichen Aspekten von der Originalversion verändert worden, so dass die zickige Diva Duden Korrektor die Installation verweigert. Mit der Originalversion von OpenOffice.org klappt es zwar, jedoch ist diese Version so gut ins System integriert wie ein Ausländerfeind im Ausland. Ich hatte also die Wahl zwischen Pest und Cholera: entweder ein gut in das System integrierte Open Office ohne vernünftige Rechtschreib- und Grammatikkorrektur, oder ein hässliches und wie ein Fremdkörper wirkendes Open Office mit ordentlicher „du-bist-zu-doof-zum-Schreiben“ Kontrolle. Dank unseres Forums war eine dritte Option gefunden – Go-OO, eine veränderte Version von OpenOffice.org, auf die auch openSUSE setzt. Und siehe da: Obwohl es der Logik zufolge hätte nicht funktionieren dürfen, kann ich mit der aktuellen Version von Go-OO unerwarteterweise auf beiden Hochzeiten tanzen und sowohl eine funktionierende Rechtschreibprüfung, als auch ordentliche Optik und Haptik genießen.
Aber zurück zum Exotenstatus und den daraus resultierenden Problemen. Da mein Hauptarbeitsgerät bis zum Zeitpunkt des Umstiegs das Mac OS X Notebook war, befanden sich sämtliche Dateien auf diesem Gerät (Dokumente, Bilder, Musik, etc.). Es galt also, diese vom Notebook auf den Desktop zu transferieren. Also Notebook hochgefahren, in den Systemeinstellungen die Dateifreigabe via SMB aktiviert und im Konquerer versucht, auf das Notebook zuzugreifen. Dass es nicht automatisch gefunden werden konnte, war verschmerzbar, über smb://IP-Adrese war ein Zugriff schließlich problemlos möglich. Doch nach einigen Minuten gab es plötzlich eine Fehlermeldung, dass eine bestimmte Datei nicht gefunden werden konnte. Woher diese Datei stammen sollte, war mir nicht klar, denn die Datei gab es tatsächlich nicht. Kurz auf dem Notebook in das entsprechende Verzeichnis navigiert und nachgeprüft – keine Datei mit diesem Namen. Wie kommt KDE3 auf die Idee eine Datei zu kopieren, die es gar nicht gibt, und sich anschließend darüber zu beschweren, dass eine Datei, die es nicht gibt, nicht gefunden und folglich auch nicht kopiert werden kann? Und es blieb nicht nur bei dieser einen Datei – die Meldung wiederholte sich alle paar Minuten für unterschiedliche Phantomdateien.
<div class="newsfloatright"><img src="http://www.planet3dnow.de/photoplog/file.php?n=7304" border="0" alt="Umlaute"></div>Da mir die Methode, die nicht vorhandenen Dateien einfach zu überspringen zu unsicher war, musste eine Alternative her. Also unter OS X den SSHD aktiviert, um mittels SFTP die Dateien zu kopieren. Funktionierte gut und diesmal ganz ohne Fehlermeldungen. Leider musste ich nach dem mehrere Stunden langen Kopiervorgang erschrocken feststellen, dass in den Dateinamen sämtliche Umlaute verloren gegangen waren – aus ä wurde ein a mit einem Kästchen darüber. Und das trotz augenscheinlich korrekter Codierung während der Übertragung (UTF-8). Andere Codierungen, zum Beispiel ISO8859-15, führten zu noch zerstückelteren Dateinamen. Offenbar ist hieran Apple schuld, da die Programmierer an der implementierten UTF-8 Codierung etwas „optimiert“ haben, was zu dem leider bekannten Fehler mit Umlauten und Sonderzeichen führt.
Es war also Zeit, die Sphäre des normalen Anwenders zu verlassen und die des Systemadministrators zu betreten, wobei natürlich fraglich ist, ob die Aktivierung des SSHD nicht bereits zumindest zwischen den Sphären liegt. Da die bisherigen Lösungen mehr als inakzeptabel waren, musste eine zuverlässige Lösung für dieses Problem her. In dem Fall war es das Einbinden des SMB-Shares via mount.cifs als root und das anschließende Kopieren der Verzeichnisse in der Konsole. Zum Schluss noch den Besitzer der Dateien und Verzeichnisse korrekt auf mj:users einstellen und sich freuen.
Ich frage mich allerdings ernsthaft, wie ein normaler Anwender ohne dem bei mir vorhandenen Hintergrundwissen die Dateien hätte kopieren sollen.
Doch zunächst galt es, den Desktop erneut von Anfang an einzurichten, diesmal mit der 32-bit Version von openSUSE, und die gleichen Probleme, die auch schon mit der 64-bit Version aufgetreten waren, zeigten auch diesmal wieder ihre hässliche Fratze: Der nicht mehr funktionierende X-Server nach der Installation von fglrx zum Beispiel, oder die kaputten Sessions tty1-tty6 bei Verwendung des fglrx-Treibers. Doch auch mit der 32-bit Version von Open Office und openSUSE schlug die Installation des Duden Korrektors fehl, diesmal allerdings mit einer nichtssagenden Fehlermeldung. Offenbar ist die Version von OpenOffice.org, die in den openSUSE Repositories feilgeboten wird, in etlichen Aspekten von der Originalversion verändert worden, so dass die zickige Diva Duden Korrektor die Installation verweigert. Mit der Originalversion von OpenOffice.org klappt es zwar, jedoch ist diese Version so gut ins System integriert wie ein Ausländerfeind im Ausland. Ich hatte also die Wahl zwischen Pest und Cholera: entweder ein gut in das System integrierte Open Office ohne vernünftige Rechtschreib- und Grammatikkorrektur, oder ein hässliches und wie ein Fremdkörper wirkendes Open Office mit ordentlicher „du-bist-zu-doof-zum-Schreiben“ Kontrolle. Dank unseres Forums war eine dritte Option gefunden – Go-OO, eine veränderte Version von OpenOffice.org, auf die auch openSUSE setzt. Und siehe da: Obwohl es der Logik zufolge hätte nicht funktionieren dürfen, kann ich mit der aktuellen Version von Go-OO unerwarteterweise auf beiden Hochzeiten tanzen und sowohl eine funktionierende Rechtschreibprüfung, als auch ordentliche Optik und Haptik genießen.
Aber zurück zum Exotenstatus und den daraus resultierenden Problemen. Da mein Hauptarbeitsgerät bis zum Zeitpunkt des Umstiegs das Mac OS X Notebook war, befanden sich sämtliche Dateien auf diesem Gerät (Dokumente, Bilder, Musik, etc.). Es galt also, diese vom Notebook auf den Desktop zu transferieren. Also Notebook hochgefahren, in den Systemeinstellungen die Dateifreigabe via SMB aktiviert und im Konquerer versucht, auf das Notebook zuzugreifen. Dass es nicht automatisch gefunden werden konnte, war verschmerzbar, über smb://IP-Adrese war ein Zugriff schließlich problemlos möglich. Doch nach einigen Minuten gab es plötzlich eine Fehlermeldung, dass eine bestimmte Datei nicht gefunden werden konnte. Woher diese Datei stammen sollte, war mir nicht klar, denn die Datei gab es tatsächlich nicht. Kurz auf dem Notebook in das entsprechende Verzeichnis navigiert und nachgeprüft – keine Datei mit diesem Namen. Wie kommt KDE3 auf die Idee eine Datei zu kopieren, die es gar nicht gibt, und sich anschließend darüber zu beschweren, dass eine Datei, die es nicht gibt, nicht gefunden und folglich auch nicht kopiert werden kann? Und es blieb nicht nur bei dieser einen Datei – die Meldung wiederholte sich alle paar Minuten für unterschiedliche Phantomdateien.
<div class="newsfloatright"><img src="http://www.planet3dnow.de/photoplog/file.php?n=7304" border="0" alt="Umlaute"></div>Da mir die Methode, die nicht vorhandenen Dateien einfach zu überspringen zu unsicher war, musste eine Alternative her. Also unter OS X den SSHD aktiviert, um mittels SFTP die Dateien zu kopieren. Funktionierte gut und diesmal ganz ohne Fehlermeldungen. Leider musste ich nach dem mehrere Stunden langen Kopiervorgang erschrocken feststellen, dass in den Dateinamen sämtliche Umlaute verloren gegangen waren – aus ä wurde ein a mit einem Kästchen darüber. Und das trotz augenscheinlich korrekter Codierung während der Übertragung (UTF-8). Andere Codierungen, zum Beispiel ISO8859-15, führten zu noch zerstückelteren Dateinamen. Offenbar ist hieran Apple schuld, da die Programmierer an der implementierten UTF-8 Codierung etwas „optimiert“ haben, was zu dem leider bekannten Fehler mit Umlauten und Sonderzeichen führt.
Es war also Zeit, die Sphäre des normalen Anwenders zu verlassen und die des Systemadministrators zu betreten, wobei natürlich fraglich ist, ob die Aktivierung des SSHD nicht bereits zumindest zwischen den Sphären liegt. Da die bisherigen Lösungen mehr als inakzeptabel waren, musste eine zuverlässige Lösung für dieses Problem her. In dem Fall war es das Einbinden des SMB-Shares via mount.cifs als root und das anschließende Kopieren der Verzeichnisse in der Konsole. Zum Schluss noch den Besitzer der Dateien und Verzeichnisse korrekt auf mj:users einstellen und sich freuen.
Ich frage mich allerdings ernsthaft, wie ein normaler Anwender ohne dem bei mir vorhandenen Hintergrundwissen die Dateien hätte kopieren sollen.
Um auf die letzte Frage zurück zu kommen. Der hätte nicht das Ntzwerk bemüht, sondern einen FAT32 formatierten USB Stick verwendet.
Außerdem würde er vermutlich kein OpenSUSE verwenden, sondern auf Ubuntu setzen und dank Debian Basis ist das etwas weniger anspruchsvoll.
Außerdem würde er vermutlich kein OpenSUSE verwenden, sondern auf Ubuntu setzen und dank Debian Basis ist das etwas weniger anspruchsvoll.
mj
Technische Administration, Dinosaurier, ,
Klar wäre das auch gegangen. Bei einer Datenmenge von ~60GB allerdings nicht ganz ohne.
Und mal ehrlich: was ist das für eine Lösung auf das Netzwerk zu verzichten und über externe Datenträger zu gehen? Ein Workaround vielleicht, ja. Aber keine dauerhafte Lösung. Schließlich muss der Datenbestand beider Computer synchron gehalten werden, wofür ich mir noch eine Lösung einfallen lassen muss. Denn die Übertragung über Netzwerk muss funktionieren, da gibt es kein wenn und aber.
Und mal ehrlich: was ist das für eine Lösung auf das Netzwerk zu verzichten und über externe Datenträger zu gehen? Ein Workaround vielleicht, ja. Aber keine dauerhafte Lösung. Schließlich muss der Datenbestand beider Computer synchron gehalten werden, wofür ich mir noch eine Lösung einfallen lassen muss. Denn die Übertragung über Netzwerk muss funktionieren, da gibt es kein wenn und aber.
Onkel Homie
Gesperrt
Ich muss sagen das ich gerade bei einer solchen Datenmenge erst gar nicht auf die Idee gekommen wäre, sie übers Netz zu schieben. Die Zeit wäre mir dafür zu schade 
HDD dran, rüberziehen und fertig. Selbst bei vielen "normalen" Anwendern findensich mittlerweile externe Platten.
Dennoch zeigen die geschilderten Probleme aber mal wieder deutlich wo es mit der Massenkompatibilität scheitert und das man mit einem Linux System an sich nur Freude haben kann, wenn in einem auch der Bastler schlummert. Dies liegt nicht immer an Linux selbst, sondern wie hier gezeigt auch gerne mal an anderen Dingen, aber man muss halt eine gewisse Bereitschaft zu leiden und zu basteln mitbringen, sonst kann man es gleich lassen.
HDD dran, rüberziehen und fertig. Selbst bei vielen "normalen" Anwendern findensich mittlerweile externe Platten.
Dennoch zeigen die geschilderten Probleme aber mal wieder deutlich wo es mit der Massenkompatibilität scheitert und das man mit einem Linux System an sich nur Freude haben kann, wenn in einem auch der Bastler schlummert. Dies liegt nicht immer an Linux selbst, sondern wie hier gezeigt auch gerne mal an anderen Dingen, aber man muss halt eine gewisse Bereitschaft zu leiden und zu basteln mitbringen, sonst kann man es gleich lassen.
mj
Technische Administration, Dinosaurier, ,
Desti: Links gab es dort keine mehr. Und soweit ich weiß beherrscht Mac OS X im Auslieferungszustand kein NFS, wobei ich mich natürlich gern korrigieren lasse. Allerdings war es in den von mir näher untersuchten Fällen immer so, dass diese Datei unter Umständen irgendwann in der Vergangenheit in diesem Verzeichnis existiert haben könnte.
Zum Thema Netzwerk: wie bereits gesagt hätte ich die 60GB natürlich auch problemlos über eine externe Festplatte übertragen können. Nur hätte ich dann spätestens bei der ersten Synchronisation über Netzwerk das gleiche Problem gehabt, mit unter Umständen noch weitaus schlimmeren Folgen als hier beschrieben.
Zum Thema Netzwerk: wie bereits gesagt hätte ich die 60GB natürlich auch problemlos über eine externe Festplatte übertragen können. Nur hätte ich dann spätestens bei der ersten Synchronisation über Netzwerk das gleiche Problem gehabt, mit unter Umständen noch weitaus schlimmeren Folgen als hier beschrieben.
Chris_Bear
Admiral Special
Synchronisation ist ja schon bei gleichstämmigen Betriebssystemen immer wieder ein Thema, da wirst du zwischen Mac OS und Linux noch Spaß haben.
Ich setze bei solchen Anforderungen inzwischen auf Subversion, das erledigt die Aufgabe recht gut. Das einzige Problem dabei ist, dass ich eben einen Rechner als Server definieren muss. Daher werd ich mir demnächst mal die diversen Cloud/Distributed CVS (z.B. Mercurial) anschauen, vielleicht wäre das für dich auch eine Idee.
Ich setze bei solchen Anforderungen inzwischen auf Subversion, das erledigt die Aufgabe recht gut. Das einzige Problem dabei ist, dass ich eben einen Rechner als Server definieren muss. Daher werd ich mir demnächst mal die diversen Cloud/Distributed CVS (z.B. Mercurial) anschauen, vielleicht wäre das für dich auch eine Idee.
Onkel Homie
Gesperrt
Kommt halt drauf an was man synchronisieren will.
An sich nutze ich auch Subversion ebenfalls für diverse Projekte, aber halt dann auch hin zu nem Projektserver. kann man ja zur Dokumentation auch z.B. an Trac anbinden, dann mit Version Control, Trac-Wiki usw. usw. Oder halt Mercurial, das hab ich noch nicht genutzt
Man könnte sonst statt eines "großen" Servers auch wunderbar ein NAS einsetzen und dann hin und her syncen. Per OpenVPN drauf und ran an die Daten halt.
Wenn man aber "nur" ein paar Dokuemnte oder so synchron halten will, wäre Subversion aber wohl etwas "überdimensioniert" würde ich mal behaupten.
An sich nutze ich auch Subversion ebenfalls für diverse Projekte, aber halt dann auch hin zu nem Projektserver. kann man ja zur Dokumentation auch z.B. an Trac anbinden, dann mit Version Control, Trac-Wiki usw. usw. Oder halt Mercurial, das hab ich noch nicht genutzt
Man könnte sonst statt eines "großen" Servers auch wunderbar ein NAS einsetzen und dann hin und her syncen. Per OpenVPN drauf und ran an die Daten halt.
Wenn man aber "nur" ein paar Dokuemnte oder so synchron halten will, wäre Subversion aber wohl etwas "überdimensioniert" würde ich mal behaupten.
mj
Technische Administration, Dinosaurier, ,
git und svn sind kompletter Overkill. Unter Windows habe ich diese Aufgabe mit Hilfe von Microsofts kostenlosem SyncToy erledigt: Software Starten, Verzeichnispaar anlegen, Synchronisationsmodus auswählen, fertig. Anschließend simple One-Click-Synchronistation für alle Verzeichnispaare. So etwas benötige ich, nicht mehr und nicht weniger. Und es muss zuverlässig laufen - ich hatte vor ein paar Jahren mal mit grsync experimentiert und die Arbeit eines kompletten Tages verloren. So etwas darf nicht passieren.
Onkel Homie
Gesperrt
Selber schreiben?
Da kann man sich doch an sich rel. fix in Java was basteln, wenn es eh nur um das Kopieren von Ordnern geht.
Gibt auch im Netz sicher schon Tools die das können und auch OpenSource sind.
Da kann man sich doch an sich rel. fix in Java was basteln, wenn es eh nur um das Kopieren von Ordnern geht.
Gibt auch im Netz sicher schon Tools die das können und auch OpenSource sind.
