ubuntuusers.de

Hallo zusammen,

ich stehe kurz vor dem Nervenzusammenbruch. Ich wollte mich heute Abend der vielen unnötigen Dolphin-Dateien ".d3lphinview" in den verschiedenen Verzeichnissen meines Rechners und der USB-Platte entledigen:

sudo find / -type f -delete -name "*.d3lphinview"

Sicherheitshalber habe ich natürlich davor überprüft, welche Dateien hierdurch erfasst werden:

sudo find / -type f -name "*.d3lphinview" > d3lphinview.list

Eher per Zufall habe ich dann bemerkt, dass die USB-Platte auf einmal anstatt 200GB auf einmal 400GB frei hatte - und der Löschvorgang war da noch nicht abgeschlossen. Also habe ich natürlich sofort diesen abgebrochen und muss nun mit dem Tool Baobab festellen, dass etliche Verzeichnisse auf der Platte komplett geleert wurden 😢

Ob auch / dementsprechend geleert wurde, merke ich dann vermutlich beim nächsten Neustart ☹ Es wäre alles nicht so gravierend, wären auf der USB-Platte nicht meine kompletten privaten Daten (Fotos, Videos, Dokumente, etc.) von etlichen Jahren davon betroffen ☹

Da ich noch nicht mal genau den Schaden überblicken kann, weiß ich auch nicht, für welche Datei-Typen ich nun einen Rettungsversuch starten soll ☹

Habe ich nun den 1. Befehl falsch interpretiert, oder habe ich hier einen ganz üblen Bug entdeckt?

Grüße Piccolino81

Das -name hätte vor das -delete gemußt, und der Test insbesondere wenn man

• ein delete macht

• mit sudo arbeitet

• über das ganze Wurzelverzeichnis arbeitet

• kein Backup hat

hätte vorher gemacht werden sollen. Ich weiß - hinterher ist man immer klüger.

Wenn Du den Rechner möglichst gar nicht benutzt, dann kann eine Datenrettung am Datenträger noch was bringen - aber im Betrieb wird mit delete freigegebener Plattenplatz bei Bedarf überschrieben.

Wie gut man selbst diversen Tools sich helfen kann weiß ich nicht. Wenn die Platte nur noch zum lesen gemounted wird, dann kann eigentlich nicht mehr kaputtgehen.

user unknown schrieb:

Das -name hätte vor das -delete gemußt

Das ist dann aber in meinen Augen ein mega BUG! Wie kann es sein, dass bei der Eingabe von Parametern die Reihenfolge insofern eine Rolle spielt, dass sich das Programm in meinem Fall dann so verhält, als ob ich den einen Parameter (-name) gar nicht angegeben hätte. Das darf beim besten Willen nicht beabsichtigt sein! Zumal das Programm still und leise seinen Dienst verrichtet hat, es also keine Datei mehr entsprechend dem -name-Parameter ausgegeben hat...

Auf jeden Fall gehört dann ein entsprechender Hinweis ins Wiki.

...und der Test insbesondere wenn man .. hätte vorher gemacht werden sollen. Ich weiß - hinterher ist man immer klüger.

Ich habe doch mittels

sudo find / -type f -name "*.d3lphinview" > d3lphinview.list

VOR dem eigentlichen Löschvorgang getestet, welche Dateien dabei erfasst werden. Die resultierende Datei enthielt lediglich passende Einträge. Oder was genau meinst Du mit Test?

Piccolino81 schrieb:

user unknown schrieb:

Das -name hätte vor das -delete gemußt

Das ist dann aber in meinen Augen ein mega BUG! Wie kann es sein, dass bei der Eingabe von Parametern die Reihenfolge insofern eine Rolle spielt, dass sich das Programm in meinem Fall dann so verhält, als ob ich den einen Parameter (-name) gar nicht angegeben hätte. Das darf beim besten Willen nicht beabsichtigt sein! Zumal das Programm still und leise seinen Dienst verrichtet hat, es also keine Datei mehr entsprechend dem -name-Parameter ausgegeben hat...

Die manpage von find sagt:

ACTIONS

• delete

Delete files; true if removal succeeded. If the removal failed, an error message is issued. If -delete fails, find's exit status will be nonzero (when it eventually exits). Use of

• delete automatically turns on the -depth option.

Warnings: Don't forget that the find command line is evaluated as an expression, so putting

• delete first will make find try to delete everything below the starting points you specified.

When testing a find command line that you later intend to use with -delete, you should explic‐ itly specify -depth in order to avoid later surprises. Because -delete implies -depth, you cannot usefully use -prune and -delete together.

Ein -delete vor einem weiteren -name habe ich noch nie gesehen - ich weiß nicht, wann sowas oder etwas ähnliches eine sinnvolle Verwendung von find ist.

Wenn ich

find -name "*.class" -size +1k -delete -print

eingebe wird gelöscht und dann der Name ausgegeben. Gebe ich ein

find -name "*.class" -size +1k -delete -name "a*"

so werden alle .class-Files die größer sind als 1k erst gelöscht, und dann wird der "a*"-Filter auf die Dateien angewendet. Find ist ein Baukasten, in dem man mehrere Aktionen zusammenstöpseln kann.

Auf jeden Fall gehört dann ein entsprechender Hinweis ins Wiki.

Ja, das Wiki hat da leider mehrere Fehler - ich bin dabei sie auszubessern und den Artikel zur Diskussion zu stellen.

...und der Test insbesondere wenn man .. hätte vorher gemacht werden sollen. Ich weiß - hinterher ist man immer klüger.

Ich habe doch mittels

sudo find / -type f -name "*.d3lphinview" > d3lphinview.list

VOR dem eigentlichen Löschvorgang getestet, welche Dateien dabei erfasst werden. Die resultierende Datei enthielt lediglich passende Einträge. Oder was genau meinst Du mit Test?

Ja, das mit dem -delete hätte man so vorher nicht testen können. Man hätte es höchstens in einem Testverzeichnis mit präparierten Duplikaten testen können.

user unknown schrieb:

Ein -delete vor einem weiteren -name habe ich noch nie gesehen - ich weiß nicht, wann sowas oder etwas ähnliches eine sinnvolle Verwendung von find ist.

Sinnvoll kann das sein, wenn danach noch andere Aktionen kommen, die man nur für einen Teil der gelöschten Dateien ausführen will

Ich habe doch mittels

sudo find / -type f -name "*.d3lphinview" > d3lphinview.list

VOR dem eigentlichen Löschvorgang getestet, welche Dateien dabei erfasst werden. Die resultierende Datei enthielt lediglich passende Einträge. Oder was genau meinst Du mit Test?

Ja, das mit dem -delete hätte man so vorher nicht testen können. Man hätte es höchstens in einem Testverzeichnis mit präparierten Duplikaten testen können.

Man könnte -delete durch -depth -print ersetzen. Oder statt -delete -exec rm {} \; benutzen (ggf. mit -depth) und zum testen rm durch echo ersetzen

Hi Piccolino,

um jetzt die Daten noch zu retten ist es vor allem wichtig, dass du die betreffenden Festplatte
jetzt vor allem nicht weiter anrührst, so wie user unknown oben schon gesagt hat.

Und dann müsstest Du mit einem Tool wie ext3grep an die Geschichte herangehen. (es ist doch eine ext3-Partition, oder ?)
Links dazu hatte ich die Tage hier schon mal gepostet: http://forum.ubuntuusers.de/post/2393470/

Und sinnigerweise arbeitest Du nur mit einer Spiegelkopie der Festplatte, denn die Datenrettung
ist schon ein heißes Eisen, bei dem auch was (dann wirklich endgültig) schief gehen kann.

LG und viel Erfolg,

track