Datei mit Sonderzeichen löschen

hallo zusammen,

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 :D)

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.)
 
hallo edi38 -

ich bräucht noch kurz eine Info:
Hast du ein Journaled Filesystem (kannst Du mt dem Kommand "mount" rausfinden)
 
Original geschrieben von maceis
Das ist so nicht ganz richtig, aber es führt vom eigentlichen Thema weg - belassen wir es also erstmal dabei.
Dann bitte mal per PN die Richtigstellung, damit's hier nicht weiter stört :D
 
hallo Synthesis-

nein lass mal, wenn dann für alle:

Der Denkfehler liegt meines Erachtens darin, dass du davon ausgehst, dass ein Name der auf der Terminalausgabe für uns durch ?? o. ä angezeigt wird von der Shell auch nicht verstanden wird.

Das Manko liegt aber nicht beim Interpreter der Shell, sondern bei der fehlenden Leistungsfähigkeit des an der Oberfläche der Shell verwendeten Zeichensatzes.

Man kann es sich etwa so vorstellen:
Du sitzt an einer amerikanischen Tastatur (Tastaturbelegungen jetzt mal außen vor) und willst eine Datei löschen, die ein ö enthält (soll sie von mir aus "schön.pdf heissen").
Da die Tastatur kein ö enthält, kannst du es nicht eingeben.
also gibts du z. B. ein:
sch?n.pdf
und alles ist gut, da die shell weiss, dass sie jede Datei löschen soll, die anstelle des Fragezeichens genau ein Zeichen enthält (das könnte sogar ein Chinesisches Schriftzeichen sein).

Gibt es keine Datei, die mit sch beginnt, dann genau ein Zeichen hat und mit n.pdf endet, kommt die Antwort no match also: nichts passt.

edi bekommt aber die Antwort no such file or directory.
Die shell findet also ein match, aber nicht eine dazugehörige Datei.
Ich vermute daher, dasss an der Stelle, im physikalischen Dateisystem (= Speicherort auf der Platte) keine Datei mit entsprechendem Inode gefunden wird.

Klingt kompliziert, ich weiss, aber für semantischen Ausarbeitung bin ich zu müde - :D

Dein Beispiel "echo *" ist auch gut in dem Zusammenhang:
Die shell weiss, dass damit alle Dateien, also auch eine Datei mit Hochbits gemeint ist, deren Name sich im eingestellten Zeichensatz nicht darstellen lässt und fügt halt Sonderzeichen (? oder /123) ein, um zu zeigen: Da ist noch was.
 
Hallo zusammen,

nochmal vielen Dank für Eure Aufmerksamkeit für das Problem.

Hier zum Stand der Dinge:
Weitere fsck_hfs brachten selbige Ergebnisse. Somit erscheint die Sache für mich im Moment in einem sehr düsteren Licht. Auch Eure Postings (Richtung Neuinstallation) scheinen nicht mehr viele Alternativen bereitzuhalten. Jedoch hat mit noch ein MacUser-Nutzer über eine Mail das Programm "Path Finder"

http://www.cocoatech.com/

empfohlen, welches ihm wohl bei einem gleichwertigem Problem geholfen hat. Da mein Problem natürlich von üblerer Sorte ist (der Sarkasmus kommt!), habe ich jetzt das Problem, dass ich keine laufende "Path Finder" Version für mein Mac OS X Server 10.1.4 finde. Kennt jemanden einen Link zu einer älteren compatiblen Version?
 
Jetzt wirds nochmal interessant!

Nach einem weiterem Tipp per Mail, habe ich ein Verzeichnis in der die Datei lag, mit dem FTP-Client "Transmit" gelöscht. Dieser hat folgendes gemacht:

1. Fehlermeldung, dass das Verzeichnis nicht gelöscht werden kann.
2. Anzeige des PDF-Files, als Grund für den Fehler. (Zum ersten mal, dass ich das File ausserhalb der Shell zu Gesicht bekommen habe.)
3. Das Verzeichnis war trotzdem gelöscht!
4. Ein Blick auf den Papierkorb zeigte, dass dieser leer ist.
5. In der Shell offenbarte sich, dass "Transmit" ein verstecktes Verzeichnis angelegt hat (Name: del01df.001), welches nun die Datei beinhaltet.

Minimaler Teilerfolg: Mein Papierkorb erscheint jetzt wieder leer. :p

Vielleicht kann ich mit "Path Finder" für Mac OS X Server 10.1.4 der Datei den Rest geben.
 
Weitere Schritte

Folgendes habe ich noch probiert:

1. Ich habe versucht mit RBrowser die Datei zu löschen. Der FTP-Client schaffts nicht.

2. Das Programm Force Delete v1.2, was vielleicht helfen könnte, ist erst ab 10.1.5 lauffähig (habe 10.1.4 Server, was nicht weiter geupdated werden kann).

3. Zum Tipp von ICEMAN via Mail: Kann leider nicht unter OS9 booten. Habe aber mit OS9.1 per FTP-Client auch keinen Erfolg gehabt.


Kann mir jemand einen Link für den Path Finder oder für Force Delete schicken, die unter Mac OS X Server 10.1.4 laufen?
 
hallo edi38,

schön, dass du noch da bist :)

im manual stehen noch zwei (oder eine) optionen von fsck_hfs, die evtl. was bringen könnten; selber hab ich sie noch nicht probiert, und man kann sie anscheinend nur jeweils einzeln anwenden.

fsck_hfs -p Preen the specified file systems.
oder
fsck_hfs -r Rebuild the catalog file on the specified file system.
This option currently will only work if there is enough
contiguous space on the specified file system for a new
catalog file and if there is no damage to the leaf nodes in
the existing catalog file.


Die zweite Variante scheint mir weniger aussichtsreich, da je bei die anscheinend ein "leaf node" beschädigt ist.

Wenn du Lust hast, kannst du es ja noch testen.
 
Hallo maceis! Ich geb nicht auf, bis mein PBook wieder suaber ist ;-)

Habe die erste Variante mal probiert, leider ohne Erfolg. Die Zweite ist mir zu gefährlich. Ich habe zwar genug Plattenplatz, aber leaf... Lieber nicht.

Kannst Du mir bei der Software weiterhelfen?
 
Zurück
Oben Unten