[10.10 Yosemite] Halbexistierende Datei kann nicht gelöscht werden

[Dennis Jackman]

Hey,

also ich habe folgendes Problem. Ich habe von meiner externen Festplatte einige Ordner auf mein MacBook Pro geschoben. Es gab keine Fehlermeldungen. Danach wollte ich die Ordner auf der Festplatte löschen, da ich sie da nicht mehr brauche. Ich konnte auch alle Ordner löschen außer einen, da dieser "noch in Verwendung ist".

Das Ding ist aber, dass der Ordner nicht in Verwendung ist. Kein Programm (außer der Finder) ist geöffnet, und es dürfte auch so oder so kein Programm geben, welches das Verzeichnis nutzt. Ich habe schon probiert die Festplatte auszuwerfen und neu zu mounten oder auch das System neu zu starten. Dann wollte ich das Verzeichnis über das Terminal löschen und da kam dann die Meldung, dass das Verzeichnis nicht leer ist. Ok.. "cd tmp/; ls -lisa" -> keine Datei. Was ich dann herausgefunden habe:

In dem gleichen Ordner auf dem Desktop (also der kopierte) fehlt eine Datei und wenn ich vi/rm/cat etc. benutze und dann per Tab auflöse, schlägt mir das Terminal diese fehlende Datei vor. Wenn ich sie allerdings mit rm löschen will, bekomme ich "No such file or directory". Völlig irrelevant ob ich das Command als Super User ausführe oder nicht. Der kopiervorgang wurde nicht richtig ausgeführt und jetzt fehlt die Datei auf dem Desktop (welches nicht schlimm ist) und Sie existiert halb auf der Festplatte (was eher das Problem ist)..

Ich habe schon im Apple Support gelesen, dass man die Datei umbenennen soll, dann mit dem umbenennten Dateinamen überschreiben soll und diese Datei könne man dann löschen, wenn es eine nicht komplett kopierte Datei ist. Aber bei mir gehts nicht, da ich die Datei nicht umbenennen kann (No such file or directory)

Kann mir da vielleicht jemand helfen?

Mit freundlichen Grüßen
Dennis

 

[Rastafari]

Möglicherweise ein falsch kodiertes Sonderzeichen im Namen oder so (welches evtl gar nicht druck- bzw sichtbar ist).
Du kannst die Tab-Vervollständigung im Terminal dioch auch beim rm-Befehl benutzen?

 

[Dennis Jackman]

Möglicherweise ein falsch kodiertes Sonderzeichen im Namen oder so (welches evtl gar nicht druck- bzw sichtbar ist).

Das kann nicht sein, da es ja vor dem kopieren von der Festplatte angezeigt wurde und auch alles funktioniert hat. Beim kopieren ist also ein Fehler aufgetreten, obwohl das macbook sowie festplatte nicht bewegt/benutzt wurde. Es handelt sich um ca. 300 MP3 Dateien und nur die eine macht probleme.

Du kannst die Tab-Vervollständigung im Terminal dioch auch beim rm-Befehl benutzen?

Ja funktioniert ja auch. Nur das Problem ist folgendes:

$ ll
ls: 20. N2N - Flöte (Original Mix).mp3: No such file or directory
total 88
36759 80 drwxrwxrwx 1 root wheel 40960 27 Sep 20:22 .
36758 8 drwxrwxrwx 1 root wheel 4096 27 Sep 19:34 ..
$
$ rm 20.\ N2N\ -\ Flöte\ \(Original\ Mix\).mp3 <- über Tab aufgelöst
rm: 20. N2N - Flöte (Original Mix).mp3: No such file or directory
$

Die Datei ist an sich nicht im Verzeichnis, aber irgendwie ja schon, da man Sie über Tabauflösung erreichen kann. Führe ich den Command dann aus, existiert die Datei dann wieder nicht

 

[Rastafari]

Das kann nicht sein

Doch, kann sehr wohl sein.
Versuch mal das 'ö' durch ein ? oder * zu ersetzen, bevor du den Befehl absetzt.
(Obacht: vermutlich besteht es in Wirklichkeit aus zwei Zeichen.)

 

[MacAlzenau]

Hast du mal versucht, den Dateinamen, ggf. mit komplettem Pfad, in Anführungszeichen einzugeben? Ist etwas irrational, ich weiß, wenn per Tab der richtige Name eingetragen wird, aber vielleicht einen Versuch wert.

 

[Dennis Jackman]

Versuch mal das 'ö' durch ein ? oder * zu ersetzen, bevor du den Befehl absetzt.

Funktioniert auch nicht. Aber es kann doch nicht sein, dass das System kein ö verarbeiten kann, wo es doch bei allen anderen Verzeichnissen und Dateien funktioniert. Außerdem hat es ja auch richtig funktioniert bevor ich die Datei kopiert habe.

Hast du mal versucht, den Dateinamen, ggf. mit komplettem Pfad, in Anführungszeichen einzugeben? Ist etwas irrational, ich weiß, wenn per Tab der richtige Name eingetragen wird, aber vielleicht einen Versuch wert.

Hat leider auch nicht funktioniert auch nicht kombiniert mit dem Lösungsvorschlag von Rastafari, also:

$ rm "/Volumes/***/***/***/20.\ N2N\ -\ Flöte\ \(Original\ Mix\).mp3"
$ rm "/Volumes/***/***/***/20.\ N2N\ -\ Fl?te\ \(Original\ Mix\).mp3"
etc. bei allen kommt immer wieder No such file or directory. Wenn ich den Inhalt des Verzeichnisses aufliste, findet er auch etwas, allerdings kann er auch nichts damit anfangen. Ebenfalls No such file.. (kann man in meinem Vorherigen Beitrag sehen)

 

[MacAlzenau]

Ich bin ja kein Terminalfachmann, aber wenn du Anführungszeichen benutzt, darfst du nicht zusätzlich per \ auskommentieren. Da muß dann der Dateiname/Pfad stehen, wie er im Finder auftaucht. Auch * und ? sind dann meiner Meinung nach ungeeignet.

 

[Dennis Jackman]

Ich bin ja kein Terminalfachmann, aber wenn du Anführungszeichen benutzt, darfst du nicht zusätzlich per \ auskommentieren. Da muß dann der Dateiname/Pfad stehen, wie er im Finder auftaucht. Auch * und ? sind dann meiner Meinung nach ungeeignet.

Achja, aber mit Standard-Leerzeichen funktioniert auch nicht.

 

[Rastafari]

Versuch mal ein Listing mit
LC_ALL=C ls -OFlab "Ordner"
(...um die wahre Natur aller UTF Multibyte-Zeichen zu sehen. Ein 'Ü' und ein 'Ü' lassen sich üüüübrigens auf mindestens vier völlig unterschiedliche Arten anzeigen. Nur weil etwas gleich aussieht, muss es noch lange nicht das gleiche sein.)
Ist die Platte zufällig Windows formatiert, bzw stammen die Daten von einem PC?

 

[Dennis Jackman]

LC_ALL=C ls -OFlab "Ordner"

Wenn ich das richtig verstanden habe, dann export ... in der profile oder? Bin gerade auf der Arbeit aber ich kann es später einmal ausprobieren.

(...um die wahre Natur aller UTF Multibyte-Zeichen zu sehen. Ein 'Ü' und ein 'Ü' lassen sich üüüübrigens auf mindestens vier völlig unterschiedliche Arten anzeigen. Nur weil etwas gleich aussieht, muss es noch lange nicht das gleiche sein.)

Ja, ich hätte jetzt nur nicht gedacht, dass OS X/Windows verschiedene Zeichencodes für so gängige Zeichen verwenden, was mich zum nächsten Punkt bringt:

Ist die Platte zufällig Windows formatiert, bzw stammen die Daten von einem PC?

Da kommen wir der Sache schon näher. Es handelt sich um eine externe Festplatte (Toshiba 2TB), die ich vorher an einem PC genutzt habe. Ich benutze einen NTFS Treiber, um Sie schreiben zu können. Lesen/Schreiben/Ausführen hat auch immer geklappt nur beim Kopieren dieses "ö" gab es jetzt Probleme.

Der Grund warum NTFS: Die Festplatte soll gelegentlich an einen Fernseher angeschlossen werden. Ich würde Sie gerne HFS formatieren, aber dann kann mein TV die Platte nicht lesen, außerdem wäre es toll wenn man sie auch an PCs lesen und schreiben könnte, da ja viele Windows nutzen (ist allerdings kein großes Problem) Eine Lösung wäre ja die Platte FAT zu formatieren, dann würde OS X, WIndows und der TV die Platte verarbeiten können. Problem: Dateien über 4 GB nicht möglich. exFAT geht auch wieder nicht, da die meisten Fernseher dieses Format nicht unterstützen. Deshalb NTFS formatiert. Kennt jemand vielleicht noch ne bessere Lösung? Ich meine mit NTFS + Treiber muss ja die Schreibgeschwindigkeit mächtig leiden.

 

[Rastafari]

export ... in der profile oder?

export ????? profile ????
Du sollst das so eingeben, sonst nichts.

hätte jetzt nur nicht gedacht, dass OS X/Windows verschiedene Zeichencodes für so gängige Zeichen verwenden

Im Unix-Bereich hat sich das effizientere UTF-8 durchgesetzt, Windows nutzt grundsätzlich UTF-16.
Daran liegt es aber nicht, dass man sämtliche Zeichen mit Dieresis sowohl nativ, als auch als eine "Simulation" aus zwei Teilzeichen ("composite", zB als ein 'u' mit unmittelbar darauf folgender, generischer Dieresis) darstellen kann.

Ich benutze einen NTFS Treiber

Lass mich raten: NTFS-3G oder Tuxera?
Da kann man nur zu Paragon-NTFS raten. Das kennt solche Zeichensatzprobleme nicht (mehr) und steht als nativer Kerneltreiber der Leistung von Mac-Volumes nicht spürbar nach. Für SnowLeopard gibts eine kostenlose Lizenz (für ein System, ggf auch innerhalb einer VM nutzbar), ansonsten kostet das aktuelle Paket so etwa 20 Steine. Bringt im Gegensatz zu 3G/Tuxera auch eine volle Integration ins Festplatten-Dienstprogramm mit, inklusive Dateisystemcheck/reparatur und der Möglichkeit in NTFS zu formatieren.
Was den Fernseher betrifft: Mach dich mal schlau, ob der auch Linux ext2/ext3/ext4 versteht.

 

[Dennis Jackman]

Dennis-MBP:tmp dennis$ LC_ALL=C ls -OFlab "ordner"/
ls: 20. N2N - Flöte (Original Mix).mp3: No such file or directory
total 88
drwxrwxrwx 1 root wheel - 40960 Sep 27 20:22 ./
drwxrwxrwx 1 root wheel - 4096 Sep 27 19:34 ../
Dennis-MBP:tmp dennis$

es muss doch eine Möglichkeit geben dieses Verzeichnis zu löschen.

ich probier mal die platte an ein PC anzuschließen und die Datei von da aus zu finden und ggf. zu löschen

---
hat funktioniert. Da gab wohl echt ein Verständnisproblem zwischen Windows und OS X.
Auf dem Windows System war die Datei ganz normal ohne Beschädigung da und konnte auch abgespielt werden, also lag es wahrscheinlich wie du sagtest daran, dass das 'ö' unter Windows anders formatiert ist.