maceis
Aktives Mitglied
- Dabei seit
- 24.09.2003
- Beiträge
- 16.880
- Reaktionspunkte
- 626
hallo zusammen,
Das ist so nicht ganz richtig, aber es führt vom eigentlichen Thema weg - belassen wir es also erstmal dabei.
Hier erstmal wie versprochen die Unicodezuweisungen:
\355 -> Kleines t mit Cedilla (so ein Haken unten dran)
\265 -> Kleines c mit Zirkumflex
\266 -> Großes C mit einem Punkt darüber
\355
\264 -> Großes C mit Zirkumflex
\242 -> Kleines o mit Grave
Die korrekte Anzeige von Sonderzeichen lässt sich in der Shell eigentlich einstellen. Bei mir hat das Ganze aber nur in der zsh (Z-Shell) funktioniert - und auch da nur eingeschränkt.
Hieraus würde ich (wenn ich das Problem hätte) schließen, dass
a) das Dateisystem beschädigt ist, und
b) der Fehlder durch das Werkzeug "fsck_hfs" ohne Angabe von weiteren Optionen nicht behoben werden kann.
Es gibt jetzt noch weitere Möglichkeiten.
Ich möchte aber nicht versäumen darauf hinzuweisen, dass jeder, der etwas ausprobiert, was ich hier poste dies ausdrücklich auf eigenes Risiko tut.
Der Hinweis ist notwendig, weil bei Beschädigungen des Dateisystems durchaus der ganze Datenbestand flöten gehen kann.
Wer mich kennt weiss allerdings, dass ich nicht unbedacht "agressive" Shell-Kommandos poste, sondern Tips nach bestem Wissen und Gewissen zu geben versuche.
Durch die Eingabe des Befehls
fsck_hfs -d name der Gerätedatei
lässt sich eine Debugging Information ausgeben, die aufschlussreich sein kann, wenn sich ein Dateisystem nicht reparieren lässt (so stehts jedenfalls im Manual )
also edi: Ausprobieren und hören lassen.
._ut hat soweit recht, nur wird das schwierig sein, wenn es sich um das Startvolume handelt.
Wenn es das Startvolume ist, kann das auch der Grund sein, warum die Reparatur fehlschlägt. Da solle das Starten von CD noch am meisten bringen (hab´s selber noch nicht versucht.)
as sollte die dann eine Liste mit allen Dateienamen geben, die die Shell daraus macht. Der springende Punkt ist, daß unser häßlicher Umlautname dann auch wieder dabei ist und somit dem Löschbefehl auch nur der Name - wie von Hand eingetippt - übergeben wird.
Das ist zwar keine Lösung des Problems, aber es erklärt,w arum auch die ganzen Platzhalteraktionen nicht funktionieren :/
Das ist so nicht ganz richtig, aber es führt vom eigentlichen Thema weg - belassen wir es also erstmal dabei.
Hier erstmal wie versprochen die Unicodezuweisungen:
\355 -> Kleines t mit Cedilla (so ein Haken unten dran)
\265 -> Kleines c mit Zirkumflex
\266 -> Großes C mit einem Punkt darüber
\355
\264 -> Großes C mit Zirkumflex
\242 -> Kleines o mit Grave
Die korrekte Anzeige von Sonderzeichen lässt sich in der Shell eigentlich einstellen. Bei mir hat das Ganze aber nur in der zsh (Z-Shell) funktioniert - und auch da nur eingeschränkt.
Auch beim vierten Durchlauf von fsck_hfs /dev/disk0s2 kam eine Fehlermeldung. Hier die Ausgabe
Hieraus würde ich (wenn ich das Problem hätte) schließen, dass
a) das Dateisystem beschädigt ist, und
b) der Fehlder durch das Werkzeug "fsck_hfs" ohne Angabe von weiteren Optionen nicht behoben werden kann.
Es gibt jetzt noch weitere Möglichkeiten.
Ich möchte aber nicht versäumen darauf hinzuweisen, dass jeder, der etwas ausprobiert, was ich hier poste dies ausdrücklich auf eigenes Risiko tut.
Der Hinweis ist notwendig, weil bei Beschädigungen des Dateisystems durchaus der ganze Datenbestand flöten gehen kann.
Wer mich kennt weiss allerdings, dass ich nicht unbedacht "agressive" Shell-Kommandos poste, sondern Tips nach bestem Wissen und Gewissen zu geben versuche.
Durch die Eingabe des Befehls
fsck_hfs -d name der Gerätedatei
lässt sich eine Debugging Information ausgeben, die aufschlussreich sein kann, wenn sich ein Dateisystem nicht reparieren lässt (so stehts jedenfalls im Manual )
also edi: Ausprobieren und hören lassen.
._ut hat soweit recht, nur wird das schwierig sein, wenn es sich um das Startvolume handelt.
Wenn es das Startvolume ist, kann das auch der Grund sein, warum die Reparatur fehlschlägt. Da solle das Starten von CD noch am meisten bringen (hab´s selber noch nicht versucht.)