• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Datei löschen nicht möglich

haehnlein

Member
Hallo,

ich habe ein seltsames Problem:

Auf meiner externen Festplatte mit ext3 gibt es einen Ordner, der 2 Dateien mit jeweils einem fehlerhaften Zeichen (�) im Dateinamen und 0B Dateigröße enthält. Der Inhalt des Ordners ist mit Dolphin darstellbar, jedoch können weder der Ordner selbst noch die enthaltenen Dateien gelöscht werden. Der Ordner kann nur mit Dolphin unbenannt werden. Auf der Konsole kann ich als root auf den Ordner weder mit cd, cp, mv zugreifen, noch mit rm löschen. ls -la zeigt diesen nicht einmal an. Mit mkdir kann ich sogar einen neuen Ordner mit gleichem Namen auf der selben Verzeichnisebene anlegen, der dann aber im Dolphin nicht sichtbar ist. Wie kann ich denn nun den fehlerhaften Ordner löschen wenn mir die Konsolenwerkzeuge gar keinen Zugang ermöglichen? ext2fsck sagt mir auf jeden Fall, dass das Dateisystem clean sei. Vielen Dank im Voraus
 

P6CNAT

Advanced Hacker
Hallo,

sowas in der Art hatte ich schon öfters, musste aber auch jedesmal ein bischen probieren.
Ursache waren Programmierfehler bei Dateizugriffen oder Windows-Programme die über Samba oder FTP solche Dateien eingebracht hatten.

Du schreibst, dass zwei Dateien im Ordner fehlerhaft sind, du aber in der Konsole nicht mit cd in den Ordner gehen kannst. Das heisst, dein Ordner enthält auch ein nicht darstellbares Zeichen.
Du kannst es mit dem find Kommando versuchen, das nimmt in der Regel Sonderzeichen mit.

Beispiel:
Code:
find . -name "*namensteil*" -exec ls -l {} \;

oder

find . -type d -name "*namensteil*" -exec ls -l {} \;

Find müsste dann den Namen des Ordners inklusive Sonderzeichens anzeigen, das könnte auch ein FormFeed sein. Wenn find den Namen richtig erfasst, kannst du das ls -l durch rm -r ersetzen. Das löscht den Ordner mit allem was darin enthalten ist.

Aber pass auf, dass find wirklich nur den einen Ordner erfasst, der rm -r Befehl hält sich nicht lange mit Fragen auf.

Gruß
Georg
 
A

Anonymous

Gast
haehnlein schrieb:
Auf meiner externen Festplatte mit ext3 gibt es einen Ordner, der 2 Dateien mit jeweils einem fehlerhaften Zeichen (�) im Dateinamen und 0B Dateigröße enthält.
.....
ls -la zeigt diesen nicht einmal an.
.... Wie kann ich denn nun den fehlerhaften Ordner löschen wenn mir die Konsolenwerkzeuge gar keinen Zugang ermöglichen? ext2fsck sagt mir auf jeden Fall, dass das Dateisystem clean sei. Vielen Dank im Voraus
Es gibt 2 Gründe warum das so sein könnte.
1. hier ist im Dateinamen ein für deinen Zeichensatz nicht darstellbares Zeichen enthalten. Das könnte zB ein ÜÄÖ sein das mit einem anderem Zeichensatz erstellt worden ist, als den den du gerade verwendest.
In diesem Fall sollte die Dateinamenverfollständigung der Bash (2 x Tabtaste nachdem der erste Teil des Dateinamens eingegeben wurde) das aber auf der Konsole hinbekommen, oder ein * im Dateinamen die Datei auf der Konsole auch finden lassen.

2. Es handelt sich wirklich um einen Filesystemfehler. Einige deiner Beobachtungen lassen genau darauf schließen. Ein normaler Filesystemcheck bei ext3 kontrolliert nur ob im Journal des Filesystems noch unerledigte Arbeiten am Filesystem vermerkt sind, wenn nicht dann ist das Filesystem "clean". Ein richtiger Filesytemcheck wird normalerweise nur alle 180 Tage oder ca 30-35 Mounts beim Systemstart gemacht. Du kannst ihn aber jederzeit auch mit der Option -f bei fsck selbst anstoßen. Bei vielen Distributionen würde auch ein Anlegen einer leeren Datei /forcefsck und anschließender reboot ausreichen.
Code:
touch /forcefsck  #als root natürlich
Siehe dazu und zu Hintergründen auch http://wiki.linux-club.de/opensuse/Bootverz%C3%B6gerungen_durch_fsck

robi
 
OP
H

haehnlein

Member
Hallo,

das Dateisystem ist wirklich clean:

# e2fsck -f /dev/sdc2
e2fsck 1.41.1 (01-Sep-2008)
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung
/dev/sdc2: 74337/12984320 Dateien (7.7% nicht zusammenhängend), 45728334/51924088 Blöcke

Das Problem konnte ich aber dennoch lösen:

Der fehlerhafte Ordner kam von meinem 2. Linux-Rechner mittels Backup mit cp -pu auf die externe Festplatte. Die beiden fehlerhaften Files (mit falschen Zeichen im Dateinamen) waren dort auch vorhanden, allerdings hatten diese nicht 0 Byte Größe. Mit dem oben beschriebenen find Befehl konnte den Ordner mit den fehlerhaften Files auf der externen Festplatte nicht ausfindig machen. Gelöst habe ich es folgendermaßen:

Auf der Konsole des Rechners konnte ich die beiden fehlerhaften Dateien auf der internen Festplatte mit rm noch problemlos löschen. Auf der externen Festplatte habe ich den Ordner in "1" umbenannt. Auf der Konsole konnte ich zwar in diesen mittels cd wechseln, aber die fehlerhaften files waren nur mit Dolphin zu sehen (find ls usw. zeigten nichts an). Löschen des Ordners "1" war dennoch unmöglich (Dolphin und Konsole). Nun habe ich den ursprünglichen Ordner der internen Festplatte (ohne Umbenennung) auf die externe Festplatte in dasselbe Verzeichnis kopiert und siehe da plötzlich konnte ich den umbenannten Ordner "1", der vorher den gleichen Namen hatte, mit den beiden fehlerhaften Dateien löschen.

Das ist schon sehr merkwürdig. Ich vermute aber, dass der cp-Befehl manchmal nicht ganz sauber funktioniert. Ich habe bei cp -upv öfter mal Probleme, vor allem wenn versteckte Dateien auf die Backup-Platte kopiert werden (bleibt manchmal hängen). Das ist mir schon auf verschiedenen Linux-Rechnern aufgefallen. Vielleicht liegt es aber auch an ext3. Was meint Ihr?

Vielen Dank nochmal für die Hilfe
 

P6CNAT

Advanced Hacker
Hi,

das ist in der Tat sehr merkwürdig und ich bin ratlos. Ich bin auch überrascht, dass du schon öfter Probleme mit dem cp Befehl hattest. Ich denke, dass der sich cp Befehl in verschiedenen Linux-Varianten nicht unterscheidet. Und ich kenne RedHat Systeme auf denen der cp Befehl täglich zum Einsatz kommt, ohne dass ich je von solchen Problemen gehört hätte.
Auch auf meinem Suse - Versionen 10.1 bis 11.0 - ist das noch nicht vorgekommen.
Mit dem reiserfs hatte ich mal Probleme, aber ist wohl eine andere Geschichte.

Frage an die Gemeinde: Gibt es Unterschiede im Source Code elementarer Linux-Befehle wie cp, mv usw. in verschiedenen Linux-Varianten?

Gruß
Georg
 
OP
H

haehnlein

Member
P6CNAT schrieb:
Auch auf meinem Suse - Versionen 10.1 bis 11.0 - ist das noch nicht vorgekommen.

Hallo,

... was nicht heißt, dass es deshalb immer und überall funktioniert. Probleme habe ich besonders bei
Code:
cp -rpuv /home /ziel
wenn dabei versteckte Dateien kopiert werden und dabei bereits ältere versteckte Dateien auf dem Quellmedium vorhanden sind. Besonders häufig ist mir das bei der Datei .thumbnails aufgefallen. Der cp-Befehl bleibt dann manchmal an einer Stelle stehen und dann passiert nichts mehr (ich lass den Rechner dann die ganze Nacht an). Die Bash ist dabei aber nicht abgeschmiert. Mit Strg+C kann ich die Operation am nächsten Tag ganz normal abbrechen.
 

P6CNAT

Advanced Hacker
Hallo,

ich habe mir zwei Testverzeichnisse auch mit ein paar Dateien, auch versteckten, angelegt und deinen Befehl ausprobiert.
Hat einwandfrei funktioniert, auch die Aktualisierung. Allerdings hatte ich auch nur eine handvoll winziger Dateien, insofern hat mein Test nur sehr begrenzte Aussagekraft.

Kopierst du die Verzeichnisse nur zur Datensicherung? Dann schaue dir mal den Befehl tar an.

GNU `tar' saves many files together into a single tape or disk archive, and can restore individual files from the archive.
Gruß
Georg
 
Oben