staging.inyokaproject.org

Hallo Ubuntuusers!

Beim Kopieren von Daten, von einer Festplatte zu einer anderen, ist zu jeder Datei auf dem Zielmedium eine identische zusätzliche Datei mit der Endung:

_qtemp_BRgGVx kopiert worden.

Also, z.B:

Brief an Opa.odt

Brief an Opa.odt_qtemp_BrgGVx

Stromrechnung zu hoch.odt

Stromrechnung zu hoch.odt_qtemp_BRgGVx

Normalerweise nutzte ich immer rsync für das Kopieren und Syncen meiner Dateien.

Ich habe aber aus Zeitgründen einfach einmal etwas über Nautilus per Drag & Drop kopiert. Dort kam dann 'Zusammenführen', oder 'Mit neuem Namen erstellen'. Jetzt wollte ich nichts überschreiben und habe dummerweise neue Namen gewählt.

Es betrifft sehr viele, (mehrere 10.000) Dateien, in unterschiedlichen Ordnern, die ich unmöglich alle von Hand löschen möchte.

Nun suche ich nach einer Möglichkeit die überflüssigen Dateien zu finden und zu löschen.

Ich würde mir hierzu gerne ein Bash-Skript schreiben. Leider sind meine Kenntnisse aber in diesem Bereich noch nicht so ausgereift und ich benötige Hilfe.

Vielen Dank schon mal!

Ist der postfix immer _qtemp_BRgGVx? Oder allgemein _qtemp_*?

Mit find pfad -name "*_qtemp_BRgGVx" kannst du dir die Dateien auflisten lassen. Mit einem -delete dann loeschen, aber aufpassen 😉

Es ist immer die gleiche Endung bei jeder doppelten Datei.

Immer:

_qtemp_BRgGVx

an jedem Ende der Datei.

Mein Befehl:

user@user-pc:/media/NAS01/E$ find -name "*_qtemp_BRgGVx"

Gibt mir die Meldung

find: ‘*_qtemp_BRgGVx’: Datei oder Verzeichnis nicht gefunden

aus.

paraplasma schrieb:

Mein Befehl:

user@user-pc:/media/NAS01/E$ find -name "*_qtemp_BRgGVx"

Gibt mir die Meldung

find: ‘*_qtemp_BRgGVx’: Datei oder Verzeichnis nicht gefunden

Das kann nicht sein. Bis Du sicher, dass Du nicht das gemacht hast?

1
2

$ find "*_qtemp_BRgGVx"
find: ‘*_qtemp_BRgGVx’: No such file or directory

Bitte gib den Befehl noch einmal im Terminal ein, wie von sebix angegeben (Copy & Paste macht das einfach 😉), und poste den Inhalt des Terminalfensters in einem Codeblock (mit Type "console")!

Also das ist die Ausgabe, der Befehl und das Ergebnis.

user@user-pc:~$ find /media/NAS01/E -name "*_qtemp_BRgGVx"
user@user-pc:~$ 

Die Dateien sind definitiv auf dem NAS.

Im Anhang zwei Bilder.

Bild 1 von meinem Thunderbird Ordner

Bild 2 ältere Daten

paraplasma schrieb:

Also das ist die Ausgabe, der Befehl und das Ergebnis.

user@user-pc:~$ find /media/NAS01/E -name "*_qtemp_BRgGVx"
user@user-pc:~$ 

Laut deinem Bild heißen die Dateien aber "_qtmp:BRgGvx" Also ohne "e" und mit kleinem "v". find sucht Case Sensitiv.

Du musst (wenn du nicht -iname statt -name verwenden willst) auf die richtige Groß- und Kleinschreibung achten. Auf dem Screenshot ist es _qtmp_BRgGvx Wenn da noch weitere Sachen wie eine Dateiendung dahinter stehen können, musst du ein Sternchen mehr setzen:

find /media/NAS01/E -name "*_qtmp_BRgGvx*" 

Asche auf mein Haupt!

Ihr habt beide recht. Wie konnten sich diese Fehler nur einschleichen?!

Nun werden die Dateien gefunden!

Wäre das der richtige Befehl um die doppelten Dateien zu löschen?

find /media/NAS01/E -name - delete "*_qtmp_BRgGvx*" 

Vielen Dank!!!

paraplasma schrieb:

Wäre das der richtige Befehl um die doppelten Dateien zu löschen?

find /media/NAS01/E -name - delete "*_qtmp_BRgGvx*" 

Der Suchbegriff muss direkt hiter -name stehen und -delete sollte kein Leerzeichen zwischen dem Bindestrich und dem Befehl haben, also eher so:

find /media/NAS01/E -name "*_qtmp_BRgGvx*" -delete 

@ seahawk1986

Danke für deine Erklärung der Syntax. So kann ich mir das auch viel besser merken.

Aber bevor ich jetzt die Daten lösche, möchte ich sie doch zu gerne noch einmal zählen.

Dazu werde ich mir jetzt erst mal "find" durchlesen.

Ich setze dann auf gelöst, wenn ich die Daten dann entfernt habe.

Danke auch an die anderen Helfer!

paraplasma schrieb:

Aber bevor ich jetzt die Daten lösche, möchte ich sie doch zu gerne noch einmal zählen.

Da es vmtl. nicht Dein Hobby ist Dateien zu Fuß zu zählen, lässt sich das einfach durch pipen an wc erschlagen.

1

find /media/NAS01/E -name "*_qtmp_BRgGvx*" | wc -l

Seebär schrieb:

paraplasma schrieb:

Aber bevor ich jetzt die Daten lösche, möchte ich sie doch zu gerne noch einmal zählen.

Da es vmtl. nicht Dein Hobby ist Dateien zu Fuß zu zählen, lässt sich das einfach durch pipen an wc erschlagen.

1	find /media/NAS01/E -name "*_qtmp_BRgGvx*" | wc -l

So ist es sicherer:

1

find /media/NAS01/E -name '*_qtmp_BRgGvx*' -printf x | wc -c

Jaja, ich weiß, die wenigsten haben Zeilenumbrüche in ihren Dateinamen. 😛

rklm schrieb:

Jaja, ich weiß, die wenigsten haben Zeilenumbrüche in ihren Dateinamen. 😛

Alles schon in Testcases geschafft, wobei das mehr Zufall war. Da war ich echt platt, dass derlei Blödsinn (Zeilenumbruch in Name) spezifiziert und erlaubt ist. Vermutlich uralte Definition und eher Bug den Feature. Analog "." als 1. Zeichen = hidden File. Aber das kann man wenigstens verwenden.

Bzgl. printf: wieder was gelernt, was ich hoffentlich nie nutzen muss.

Seebär schrieb:

rklm schrieb:

Jaja, ich weiß, die wenigsten haben Zeilenumbrüche in ihren Dateinamen. 😛

Alles schon in Testcases geschafft, wobei das mehr Zufall war. Da war ich echt platt, dass derlei Blödsinn (Zeilenumbruch in Name) spezifiziert und erlaubt ist. Vermutlich uralte Definition und eher Bug den Feature.

Nee, ich denke, das ist ein Feature. Das ist schon urlange unter Unix-artigen Betriebssystemen so. Soweit ich aus dem Kopf weiß, dürfen nur "/" und "\0" (ASCII NUL) nicht in Dateinamen vorkommen. Aber das kann man bestimmt auch im POSIX-Standard nachschauen. Warum sollte man Dateinamen auch künstlich einschränken? Das machen doch nur Betriebssysteme, die kein Konzept vom Mounten hatten und deshalb mehrere Geräte durch Buchstaben adressieren mussten. 😈

Analog "." als 1. Zeichen = hidden File. Aber das kann man wenigstens verwenden.

Das ist kein Bug - der Punkt ist ein legales Zeichen und es gibt einfach die Konvention, das bestimmte Werkzeuge Namen mit einem führenden Punkt anders behandeln - ls beim Anzeigen, sh beim Globben.

Bzgl. printf: wieder was gelernt, was ich hoffentlich nie nutzen muss.

Das ist bei find aber sehr nützlich, weil man damit Teile das Dateinamens und andere Informationen extrahieren kann!