Fehlermeldungen beim Löschen von Dateien

f.gruber

f.gruber

Eroberer
Hallo,
ich bekomme beim Löschen eines Verzeichnisses Fehlermeldungen und kann daher dieses Verzeichnis nicht löschen.
Beispiel:
Code:
rm Downloads -R
rm: Entfernen von „Downloads/BlendKdmTheme.tar.gz“ nicht möglich: Eingabe-/Ausgabefehler
rm: Entfernen von „Downloads/.directory“ nicht möglich: Eingabe-/Ausgabefehler
rm: Entfernen von „Downloads/FreePDF4.02.EXE“ nicht möglich: Eingabe-/Ausgabefehler
Wenn ich in dieses Verzeichnis hineinschaue, sehe ich folgendes:
Code:
-????????? ? ? ? ?             ? BlendKdmTheme.tar.gz
-????????? ? ? ? ?             ? .directory
-????????? ? ? ? ?             ? FreePDF4.02.EXE
Das ganze ist auf einer externen Festplatte, die über USB angeschlossen ist. Dateisystem: ext3

Ich nehme an, dass ich die Platte neu formatieren muss. Falls sich das aber vermeiden lässt, wäre es mir lieber.
 
Ich wuerde mir eher eine neue Platte kaufen - ich kenne solche Anzeigen mehr von defekten Platten. Vorher kannst Du ja mal noch e2fsck drueber laufen lassen, um zu sehen, ob das hilft... Schau auch mal nach dem Loeschversuch mittels 'dmesg' nach, ob dort noch weitere Fehlermeldungen stehen!
 
... hast du schonmal einen fsck versucht?
Nach einigen Stunden (500 GB Platte) lieferte mir
Code:
fsck.ext3 -pcfv /dev/sdb1
folgendes:
Code:
/dev/sdb1: Updating bad block inode.
/dev/sdb1: Bad Block Inode hat unzulässigen Block(s).  

/dev/sdb1: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN
        (d.h. ohne -a oder -p Option)
Werde das, was hier vorgeschlagen wird, morgen machen.
 
Solange hier niemand andere Erfahrungen gemacht hat, moechte ich gerne nochmal darauf hinweisen, dass das oft bedeutet, dass die Platte bald ganz hinueber ist und ich mir sofort eine neue zulegen wuerde.
 
@rikola bei über 90% der fälle gebe ich dir recht, aber ich hab auch schon sachen erlebt, das ext3/4 einfach mal teile selbst zerschossen hat. Wie dem fs das gelungen ist ka :) ....
bevor ich die komplett in die tonne treten würde => S.M.A.R.T ;)

@ferdinand, an deiner stelle würde ich ein y mitgeben :> sonst darfst du hundermal+ y drücken um zu bestätigen ;)
 
@rikola bei über 90% der fälle gebe ich dir recht, aber ich hab auch schon sachen erlebt, das ext3/4 einfach mal teile selbst zerschossen hat. Wie dem fs das gelungen ist ka :) ....
Jetzt wo Du es sagst - wenn man eine USB-Platte rauszieht, bevor das Journal vollstaendig geschrieben wurde, kann das vorkommen. Und das Journal wird beim Aushaengen manchmal erst geschrieben _nachdem_ der Prompt nach einem 'umount' wieder erschienen ist.
 
ok das habe ich eher nicht gemeint, da ich keine usb-platten habe :) aber das stimmt auch ! deswegen sollte man auch immer ein umount machen und nnicht einfach raus ziehen :)
 
Habe also folgendes Kommando abgesetzt:
Code:
fsck.ext3 -cfv /dev/sdb1
Hat Stunden gedauert. Immer wieder "j" gedrückt.
Dann, als fast alles fertig war, habe ich einmal "n" gedrückt bei der Frage, ob ein Verzeichnis repariert werden soll, da ich dieses ja ohnehin nicht brauche.

Daraufhin hat sich fsck.ext3 beendet.

Ein zweites Mal mache das nicht mehr!
Daher habe ich die Platte jetzt formatiert. X(
 
Zuletzt bearbeitet:
Ich hab dir ja gesagt gib die Option -y mit um genau das zu vermeiden ;) .... dann ist das ding nämlich ruck zuck durch
 
Ich hab dir ja gesagt gib die Option -y mit um genau das zu vermeiden ;) .... dann ist das ding nämlich ruck zuck durch

Ja, ich habe den Fehler gemacht, die Option -p zu nehmen (beim ersten Versuch). Also beim nöchsten Mal werde ich hoffentlich alles richtig machen ... :brav:
 
Ansonsten kann man auch yes | fsck machen :)
Hast du denn mal mit SMART auf die Platte geguckt?
 

Ähnliche Themen

Wie bewegt Ihr zügig große Datenmengen von A nach B?

MacBook Pro hat Benutzer-Konten vergessen

Eigener Multiboot USB Stick - scheitert schon an GRUB 2

Backup Skript automatisch ausführen mit udev

Doppelte Dateien finden und löschen

Zurück
Oben