Datei mit merkwürdigen Zeichen im Dateinamen unter OS X entfernen

4087
SiggyF

Nach einem Speicherfehler in meinem Programm stecke ich mit einer Datei mit einem merkwürdigen Dateinamen fest. Es ist ziemlich resistent gegen alle normalen Methoden, um Dateien mit seltsamen Namen zu entfernen.

Der Dateiname lautet:

% 8BUȅ҉% 95d% F8% FF% FF \ x0f% 8E% 8F% FD% FF% FF% 8B% B5T% F8% FF% FF% 8B% 85 \% F8% FF% FF \ x03% 85x% F8% FF% FF% 8B% 95D% F8% FF% FF% 8B% BD% 9C% F8% FF% FF% 8D \ x04% 86% 8B% B5 @% F8% FF% FF% 89% 85% 90% F8 % FF% FF% 8B% 85X% F8% FF% FF \ x03% 85% 9C% F8% FF% FF% C1% E7 \ x02% 8B% 8Dx

Ich habe folgendes versucht:

  • rm *
      → No such file or directory
  • rm -- filename
      → No such file or directory
  • rm "filename"
      → No such file or directory
  • ls -i um die Inode-Nummer zu erhalten
      → No such file or directory
  • stat filename
      → No such file or directory
  • zip das Verzeichnis, in dem sich die Datei befindet
      → error occurred while adding "" to the archive
  • Verzeichnis im Finder löschen
      → error -43
  • in Python: os.unlink(os.listdir(u'.')[0])
      → OSError-No such file or directory
  • find . -type f -exec rm {} \;
      → No such file or directory
  • überprüft auf Sperren der Datei mit lsof
      → no locks

Alle diese Versuche führen zu einer Datei (langer Dateiname hier), die nicht gefunden wurde, oder Fehler -43. Sogar die ls -i.

Ich konnte keine weiteren Optionen finden. Bevor ich mein Dateisystem neu formatierte oder reparierte ( fsckmöglicherweise hilfreich), dachte ich, vielleicht habe ich etwas vermisst.

Ich habe dieses kleine C-Programm geschrieben, um die Inode-Nummer zu erhalten:

#include <stdio.h> #include <stddef.h> #include <sys/types.h>  int main(void)  { DIR *dp; struct dirent *ep;  dp = opendir ("./"); if (dp != NULL) { while (ep = readdir (dp)) { printf("d_ino=%ld, ", (unsigned long) ep->d_ino); printf("d_name=%s.\n", ep->d_name); } (void) closedir (dp); } else perror ("Couldn't open the directory");  return 0; }

Das funktioniert. Ich habe jetzt die Inode-Nummer, aber die normale funktioniert nicht. Ich denke ich muss das jetzt benutzen .find -inum inode_num -exec rm '{}' \;clri

5
Warum neu formatieren? Verursacht diese Datei Probleme? Wo befindet sich die Datei? Haben Sie versucht, in einem Apple-Forum zu posten? FrustratedWithFormsDesigner vor 14 Jahren 0
Wird `ls -i` die Datei auflisten? Wenn ja, aber Sie können es nicht basierend auf dem Inode löschen, es hört sich an, als sei das Dateisystem beschädigt. Bobby vor 14 Jahren 0
Die `ls -i`,` ls -i Dateiname` und `ls -i *` alle geben den Fehler 'Datei nicht gefunden' aus. Ich habe das Verzeichnis, in dem sich die Datei befindet, in den Papierkorb verschoben, aber jetzt gibt mir der nicht leere Papierkorb ein unordentliches Gefühl. Also werde ich weiter versuchen, es aufzuräumen. Ich habe es zuerst hier veröffentlicht. SiggyF vor 14 Jahren 1
Können Sie die Datei in Finder umbenennen und dann entfernen? http://support.apple.com/kb/TS2039 Doug Harris vor 14 Jahren 0
Danke, ja, ich habe versucht, es im Finder zu entfernen und `mv` zu verwenden. Finder gibt den Fehler -43 und mv gibt den Fehler "Datei nicht gefunden" aus. SiggyF vor 14 Jahren 0

5 Antworten auf die Frage

1
bryan

Versuchen 

find . -type f -exec rm {} \;

Haben Sie versucht, das übergeordnete Verzeichnis zu löschen?

Danke für die Vorschläge. Das `find` gibt auf dem` find ein "No such file oder directory" aus. -type f`. Ich habe versucht `rm -r` des Elternteils und das Verzeichnis im Finder zu entfernen. Es wird den Papierkorb nicht bereinigen, wenn ich diese Datei darin ablege. Es heißt: Vorgang kann nicht abgeschlossen werden, da das Element "myusername" verwendet wird. SiggyF vor 14 Jahren 1
eine Chance, dass die Datei geöffnet ist? kannst du es mit lsof überprüfen? bryan vor 14 Jahren 0
Ich glaube nicht Du meinst wie "mv Dateiname / dev / null"? Ich denke nicht, dass das für jede Datei funktioniert. SiggyF vor 14 Jahren 0
Die Datei ist nicht gesperrt. Ich habe es mit lsof überprüft und neu gestartet. SiggyF vor 14 Jahren 0
1
Graham Perrin

Assuming that the file system is something other than JHFS+

Symptoms may be indicative of a normalisation issue.

In the ZEVO support forum, NFD: normalization=formD (normalisation form D) includes a partial transcript from panel discussion at the 2012 Illumos ZFS Day:

… subtle bugs that, I feel like no-one else would appreciate my pain. Like in the Unicode space there's actually two different ways to store, several characters – like an é on the Mac traditionally is stored as an e and an ´ character. When it's rendered they composite them.

On any other platform … store composite characters … one click, one character.

So on the Mac, without intervention, you can get into some nasty problems because the Finder stores it one way, Terminal chose a different way. So you can actually go into the Finder and create a directory – café – then go into the Terminal and 

touch café

then you have two objects – you have a directory and a file with exactly the same name, which is, it leads to all kinds of … (!) … it looks the same but unlike … where you have differentiator, there's nothing, it's like, and in the Finder, depending on the Finder view you get different experiences. Sometimes you see two folders, sometimes you see a folder and a file, sometimes you see one folder. It's like, it's bizarre. So unfortunately …

… there's a formD-explicit setting so, on the Mac we highly recommend and in fact that's the default, you should use formD so then that problem, you can't do that – when you do the touch it'll actually map it back to the correct way.

You pay a little bit of an overhead but you can keep your sanity. It's crazy to have different stacks using different variants of the encoding.

– http://www.ustream.tv/recorded/25862520 around 00:10:33 on the timeline.

1
mainzelM

Für mich

find parent-folder -delete

Problem gelöst. Achtung: Dadurch wird natürlich der gesamte übergeordnete Ordner gelöscht!

Ich bin offen, dem unerklärlichen Downvote entgegenzuwirken. Zugegeben, dies ist möglicherweise nicht die beste Lösung und funktioniert möglicherweise nicht in allen Fällen. Dies sind Gründe, warum diese Antwort weniger nützlich erscheint. Es ist jedoch ein neuartiger Ansatz, an den jemand vielleicht nicht sofort denkt, und daher halte ich es für sinnvoll, als mögliche Alternative nachzudenken. TOOGAM vor 9 Jahren 0
Ich habe kein Downvote, aber ich habe ein Problem mit dieser Antwort: Es gibt keinen logischen Grund, warum es funktionieren sollte, wenn die anderen Dinge versucht wurden (`rm *`, lösche das Verzeichnis im Finder, `find. -Type f -exec rm {} \; `, wobei` rm -r` im übergeordneten Verzeichnis usw. ausgeführt wird, funktionierte nicht. Wenn die OP klingelt und sagt: "Ja, das hat für mich funktioniert, wenn nichts anderes getan hat!", Dann kann ich das bestätigen. (Dies erscheint jedoch unwahrscheinlich; SiggyF hat in den letzten fünf Jahren wahrscheinlich das Dateisystem in den Hintergrund gesetzt und / oder den Computer weggeworfen.)… (Fortsetzung) Scott vor 9 Jahren 0
(Fortsetzung)… Wenn mainzelM zurückkommt und sagt: "Ich habe * jede andere Lösung * auf dieser Seite vorgeschlagen, und keiner von ihnen hat gearbeitet, und dieser hat es getan", dann kann ich es ernst nehmen. Wenn jemand erklären kann, warum diese Antwort funktionieren sollte, wenn alle anderen fehlgeschlagen sind, kann ich sie aufheben. Da uns diese Dinge fehlen, wissen wir nur, dass mainzelM ein Problem hatte, das mit einer Handgranate gelöst wurde (und vielleicht nicht wirklich das gleiche wie bei den OPs) (und er beschreibt nicht einmal, was sein Problem war). Daher halte ich das nicht für eine gute Antwort. Scott vor 9 Jahren 0
Der Grund, warum `-delete` funktionieren kann, wenn die anderen Ansätze fehlschlagen, ist, dass in diesem Fall der Dateiname nicht von einem Programm an ein anderes übergeben wird, sondern` find` die Datei selbst löscht, indem ein Betriebssystemaufruf verwendet wird. Wenn Sie `rm *` verwenden, übergibt die Shell den Dateinamen an `rm`. Wenn der Dateiname Zeichen enthält, die nicht als Programmargument übergeben werden können, schlägt` rm` fehl. Einige für `find ... -exec rm {} \;`. Und ja, es hat mir in einer ähnlichen Situation geholfen. mainzelM vor 9 Jahren 0
1
TOOGAM

Ich konnte keine weiteren Optionen finden. Bevor ich mein Dateisystem neu formatierte oder reparierte (fsck könnte helfen), dachte ich, vielleicht habe ich etwas vermisst.

Nein, du warst gründlich. Anscheinend gibt es ein Problem mit einem Teil des Dateisystems. Sie könnten es reparieren. Oder Sie könnten darüber nachdenken, welchen anderen Spaß Sie machen möchten. Die einfache Sache ist jedoch, es zu reparieren.

Möglicherweise zögern Sie nicht, das Dateisystem zu reparieren: Es gibt eine sehr geringe, aber bestehende Chance, dass die Reparatur katastrophale Folgen haben könnte. Der beste Weg, sich davor zu schützen, ist die Sicherung aller wichtigen Daten. Stellen Sie sicher, dass Ihre Sicherungen in einwandfreiem Zustand sind, bevor Sie das Dateisystem reparieren.

Starten Sie dann die Reparatur. Wenn Sie wissen, was zu tun ist, benötigen Sie manchmal nur den Mut, um fortzufahren. Sie werden feststellen, dass dies in weniger als einer halben Sekunde vollständig gelöst ist. (Oder vielleicht etwas länger, wenn es etwas mehr Zeit gibt ... 3 Sekunden.)

Wenn Sie mit beschädigten Daten spielen, besteht auch die Gefahr, dass weitere Dateisystemprobleme auftreten. Wenn Sie also versuchen, sicher zu gehen, sollten Sie die vorläufige Überprüfung durchführen (was Sie bereits getan haben) und sich dann um das Problem kümmern (nach Überprüfung der Sicherungen).

Ehrlich gesagt, ich bin nicht sicher, ob das auch wirklich eine Antwort ist. Abgesehen von den trivial offensichtlichen Ratschlägen, alles vor einem drastischen Vorgehen zu sichern, trägt dies nicht zu dem bereits Gesagten bei. Scott vor 9 Jahren 0
Die Hauptaussage lautet: "Das Spielen mit beschädigten Daten birgt auch ein Risiko", so dass der richtige Prozess darin besteht, fortzufahren, anstatt herumzusitzen und zu hoffen, einen Weg zu finden, um eine stärkere Bestätigung zu erhalten. Die grundlegende implizierte Frage lautet: "Was ist der nächste Schritt?", Und ich gebe eine eindeutige Antwort zusammen mit einem Grund dafür. TOOGAM vor 9 Jahren 0
0
Brian Postow

Normalerweise öffne ich den umschließenden Ordner im Emacs-Direktmodus und markiere und lösche dann.

Danke für den Vorschlag. Beim Starten von dired in diesem Verzeichnis bekomme ich den Fehler: "Listing Verzeichnis ist fehlgeschlagen, aber 'Zugriffsdatei' hat funktioniert." Ich habe es auch mit Aquamacs probiert, gleicher Fehler. SiggyF vor 14 Jahren 1

Verwandte Probleme