Datei mit Sonderzeichen löschen

Es ist verrückt! Wenn ich ls -li eingebe kommt:

ls: sch??nen dank.pdf: No such file or directory

@dylan: Man kann sicher davon ausgehen, dass die Datei nicht "schönen dank.pdf" heisst, wie man eigentlich vermuten würde. Wie der richtige Name ist, weiss ich leider nicht. Ich habe Sie per FTP auf mein Powerbook gebracht und jetzt habe ich den Salat. (Quelle der Datei ist ein Freund, für den ich die Daten zwischenspeichern sollte, damit er sein System neu einrichten konnte. Er weiss aber auch nicht mehr, wie die Datei heissen könnte.)
 
Also das Leerzeichen sollte auch mit \ auszukommentiert werden (also rm sch?????en\ dank.pdf) bzw. der Dateinamen in Anführungszeichen gesetzt (also rm 'schönen dank.pdf' bzw. wird daraus bei der Eingabe rm 'sch\303\266nen dank')

BTW, eine Datei, die "Schönen Dank" heißt, wird im Terminal mit "scho??nen dank" bezeichnet, nicht mit "sch?????en dank".
 
jetzt wird es krank... aber verschieb Dir Datei mal in einen Ordner und versuch den Ordner mit rm -R Ordner zu löschen samt Inhalt... vielleicht klappt ja das....
 
Auch rm -R gibt die Meldung "rm: ...: No such file....".

Ich glaube das eins dieser Sonderzeichen extrem tricky ist. Hier nochmal die UNICODEs

\355\265\266\355\264\242
 
hallo edi

vielen dank für deine PN, hätte den thread sonst nicht gefunden.
Das ist ja mal eine sehr gute Frage.

Ich kann jetzt auf die Schnelle erstmal nur folgenden Vermutungen anstellen:

(Die Nummern, damit Ihr weniger schreiben müsst um Kommentare abzugeben)

1. Ich bin mir fast sicher, dass das Problem nicht mit dem Dateinamen zu tun hat.

2. Ich nehme an, dass die Datei nicht mehr existiert, bzw. der Cluster-Eintrag in der Inodetabelle und der tatsächliche Speicherort der Datei nicht mehr übereinstimmen.

3. Ein schneller Versuch wäre noch möglich:
In des Verzeichnis wechseln, in dem (nur) die Datei liegt.
rm -f s*
Vorsicht: es werden alle Dateien gelöscht, die mit s beginnen
oder
rm -f *
Vorsicht: es werden alle Dateien gelöscht
(Damit kann man definitiv ausschließen, dass der Dateiname für den Effekt verantwortlich ist)

Option -f: force delete

4. Das Nächste was ich versuchen würde, wäre ein Dateisystemcheck.
Dazu ist aber erstmal manual lesen (man fsck, man fsck_hfs und für ganz Harte evtl. noch man fs) angesagt, denn Fehler beim Bearbeiten des Dateisystems können übel sein.
Normalerweise sollte aber nix Schlimmes passieren.

Mit
sudo fsck
könntest du schon mal prüfen, ob was gefunden wird.
Es kommt dann bei jedem gefundenen Fehler eine interaktive Abfrage, ob der Fehler repariert werden soll.
Wenn was gefunden wird, und du bist unsicher, würde ich erstmal nix machen.

5. Ich glaube aber, dass die Chancen nicht so rasend groß sind, da ein Filesystem-Check ohnehin beim Booten durchgeführt wird.

Lass hören wie´s gegangen ist.
Das sind die Problemchen, die ich liebe.

Wenn das alles nicht hilft, gehts wahrscheinlich nur noch mit Werkzeugen wie DiskWarrior oder TechTool Pro.
Alternativ: Formatieren und Installieren, oder Datei unsichtbar machen und damit leben :D
 
Selbst rm -f bringt nichts.

Bei fsck passiert nichts. Nach Ausführung des Befehls kommt sofort wieder der Prompt. Kein Output von fsck.

Es ist richtig, dass die Datei nicht mehr im ursprünglichen Verzeichnis liegt. Ich hatte sie mit vielen anderen Files in vielen Verzeichnissen in den Papierkorb geschoben und als ich jetzt den Papierkorb leeren wollte, da hat er alle Files bis auf dieses gelöscht. Jetzt liegt die Datei allein auf dem Desktop, wird nicht angezeigt, aber im Terminal hat noch da.
 
hallo edi,

okay, hab jetzt mal auf die Schnelle man fsck gemacht.

kann Dir nur folgende Hinweise geben ohne länger früber nachzugrübeln.
(Eile ist übrigens ganz schlecht bei sowas)

1. Gib den Befehl
mount
ein.

Du erhältst (abhängig von Deiner Umgebung) eine Tabelle, in der Du die Gerätedateien siehst, unter denen deine Volumes hängen.
Eine typische Zeile sieht etwa so aus:
/dev/disk1s12 on /Volumes/01 Home (local, journaled)
Um nun deine Volumes mit fsck zu checken gibts du für jedes Volume folgendes ein:
sudo fsck_hfs /dev/disk1s12

Wenn du die Journaling-Funktion aktiviert hast, brauchst du noch die Option -f (für force).
OS X macht allerdeing beim Reboot ohnehin einen FS-Check

kurze Erklärung für Interessierte (alle anderen mögen sich bitte den Hinweis sparen, dass sie das nicht interessiert - ok ?)
"/dev" sind Unix Gerätedateien mit deren Hilfe du die Hardware ansprechen kannst (musst)
"disk" ist eine Festplatte oder ähnliches
die Nummer ist die Nummer der Platte (beginnend bei 0)
"s" steht für slice und meint die Partition, wobei die ersten 5-8 den Treibern u. ä. vorbehalten sind
und dann halt die Nummer der Partition.

Damit solltest du in der Lage sein alle Partitionen zu checken.
Ohne Gerätedatei gings nicht, weil “fsck“ die Datei "/etc/fstab" liest, die unter Mac OS X nicht wirklich benutzt wird und außerdem standardmäßig keine hfs Partitionen prüft.

Die Augabe könnt in etwa so aussehen:
sudo fsck_hfs /dev/disk2s12
** /dev/disk2s12
** Checking HFS volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume 01 Home appears to be OK.
 
OK. Ich habe jetzt fsck_hfs /dev/disk0s2 ausgeführt und er hat folgendes Ergebnis ausgegeben:

** /dev/rdisk0s2
** Root file system
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
Invalid leaf record count
(It should be 203840 instead of 203842)
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** Repairing volume.

***** FILE SYSTEM WAS MODIFIED *****

***** REBOOT NOW *****

Genau das werden ich jetzt auch machen (rebooten) und bin gleich wieder da.
 
hallo edi -

sieht soweit recht vielversprechend aus :D
mal sehn was draus wird.

eigenartig allerdings, dass es bei dir s2 ist -
scheint ne ziemlich jungfräulich Platte zu sein und wahrscheinlich nur eine Partition -
bisher hats bei mir immer frühestens mir s9 angefangen (wieder was gelernt)
 
Zuletzt bearbeitet:
Lade Die einfach PathFinder oder ein FTP programm wie Transmit runter, mit denen kannst Du alles ohne großen Aufwand löschen. Du kannst Dir auch unsichtbare Dateien anzeigen lassen.
PathFinder öffnen rechts klick oder Control+ klick auf die Datei und sicheres löschen wählen.
Die Programme findest Du bei versiontracker/macosx/
Gruß
 
Es ist leider alles unverändert. Alle Befehle scheitern.

Ich glaube, dass bildlich gesprochen die Datei sich nicht greifen läßt. Sie ist wie eine nasse Seife für die Befehle, da ja immer die Meldung "no match" oder "No such file..." kommt. Und dadurch funktioniert ja nicht mal die Auslesung der Inode-Nummer. Sie steht also im Filesystem aber jeder Zugriff scheitert.
 
hallo edi,

das ist aber sehr eigenartig - lass uns mal drüber schlafen.
Ich nehme an, dass es sich um Deine Startpartition handelt, sonst hättestdu noch Erste Hilfe verwenden können.

Wenn das alles nichts gebracht hat, glaub ich, dass du Spezialwerkzeug brauchst.
Versuch mal, ob du ne DEMO-Version von "DiskWarrior" findest.

--
ach und noch was fällt mir da ein-
manchmal muss man fsck mehrmals durchführen, bis er keine Fehler mehr findet - versuchen schadet ja nix.
 
Zuletzt bearbeitet:
@maceis: Vielen Dank für Deine Hilfe soweit! clap

Ich denke immernoch, dass es an einem dieser Sonderzeichen liegt. Kann jemand herausbekommen was die UNICODEs

\355\265\266\355\264\242

bedeuten?
 
Hi, ich habe das gleiche Problem mit Dateien auf einem Onlineserver ;)

Hierbei handelt es sich um folgende Dateinamen:

-rwxrwxrwx 1 54300 nobody 17976 Nov 29 2002 Britney Spears - I love Rock\'n Roll.mid
-rwxrwxrwx 1 54300 nobody 48315 Jan 19 2003 California Dreamin\'.mid

Löschen kann man diese auch nicht. Ich habe ebenfalls alle Tips diesen Thread probiert und bekomme die gleichen Fehlermeldungen.

Yves
 
hallo alle,
hallo Yves,

Hierbei handelt es sich um folgende Dateinamen:

-rwxrwxrwx 1 54300 nobody 17976 Nov 29 2002 Britney Spears - I love Rock\\'n Roll.mid
-rwxrwxrwx 1 54300 nobody 48315 Jan 19 2003 California Dreamin\\'.mid

damit bekräftigst Du meine Vermutung, dass es sich bei dem Problem nicht um die Dateinamen handelt.

Ich nehme an, du hast
rm "Britney Spears - I love Rock\\'n Roll.mid"
etc. schon versucht.
Hast du die Backslashes jetzt selber reingemacht, oder sind die im Dateinamen?
Falls ja, Veruch mal
rm Britney Spears - I love Rock\\\\'n Roll.mid

erster Backslash maskiert den zweiten Backslash, zweiter Backslash maskiert den Tick.
Und nochwas (sicherheitshalber):
Um eine Datei löschen zu dürfen, muss man nicht Schreibrecht auf die Datei, sondern auf den enthaltenenden Ordner haben, aber das hast Du wahrscheinlich ohnehin, oder ?

----

rm -f *
beweist allerdings ganz sicher (geht bei dem OnlineServer sicher nicht, aber bei "schönen Dank", dass es nicht der Dateiname ist, da hiermit alle Dateinamen gelöscht werden.

Kann jemand herausbekommen was die UNICODEs

\355\265\266\355\264\242
Ja kann ich, wenn Du bis heute Abend Zeit hast. (Hab ne Tabelle).

Ich hab noch mehr Tricks auf Lager, aber die Zeit reicht jetzt nicht.

Frage an einen Mod:
Kann man hier Teile von Beiträgen so maskieren, dass Sie als NurText dargestellt werden ?
 
Zuletzt bearbeitet:
Original geschrieben von edi38
Kann jemand herausbekommen was die UNICODEs
\355\265\266\355\264\242
bedeuten?
 
Das ist natürlich eine schöne Suchaufgabe; diese Tabelle habe ich gefunden, und sie sieht vielversprechend aus. Aber leider kommt zB \355 gar nicht darin vor ...
:confused:
Gruss, neptun
 
Schönen guten Morgen,

die Nacht ist vorbei, aber das Problem ist noch da.

@Yves: Du Glücklicher (Entschuldige bitte meinen leichten Anflug von Sarkasmus)! Ich wäre froh, wenn sich die Datei in der Form

drwxr-xr-x 6 admin staff 264 Feb 2 01:04 Public

anzeigen lassen würde. Ich bekomme mein fehlerhaftes File nur mit ls zu Gesicht und würde eigentlich gern mal wissen, wie groß es ist.

Also ich habe jetzt fsck_hfs /dev/disk0s2 bereits dreimal durchgeführt und jedesmal kommt eine Meldung ähnlich der bereits geposteten. Was bedeutet das?
 
Original geschrieben von maceis
rm -f *
beweist allerdings ganz sicher (geht bei dem OnlineServer sicher nicht, aber bei "schönen Dank", dass es nicht der Dateiname ist, da hiermit alle Dateinamen gelöscht werden.
Nein, das denke ich nicht. Die Platzhalter werden nämlich von der Shell evaluiert. Probier mal in einem Verzeichnis (das Dateien enthält) den Befehl
echo *
Das 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 :/
 
Bei echo * kommt auch no match.

Auch beim vierten Durchlauf von fsck_hfs /dev/disk0s2 kam eine Fehlermeldung. Hier die Ausgabe:

** /dev/rdisk0s2
** Root file system
** Checking HFS Plus volume.
** Checking Extents Overflow file.
** Checking Catalog file.
Invalid leaf record count
(It should be 203842 instead of 203844)
** Checking multi-linked files.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** Repairing volume.

***** FILE SYSTEM WAS MODIFIED *****

***** REBOOT NOW *****

Es ändern sich immer nur die beiden Ziffern.
 
Von dem mit dem
"Invalid leaf record count
(It should be xxx instead of xxy)"
-Problem und den Zahlen, die sich nach jeder Reparatur ändern, habe ich schon ein paar wenige male gelesen.
Soweit ich weiß, lässt sich nicht beheben, außer durch Neuformatiereung der Festplatte. Jedenfalls hab ich von keiner anderen Lösung gelesen.


Übrigens ist es besser, wenn Du fsck im Single-User-Modus ausführst (ohne das Dateisystem vorher zu mounten; Starten mit Apfel-S) oder aus dem Festplatten-Dienstprogramm auf der Mac-OS-X-CD (Starten mit C).
 
Zurück
Oben Unten