Hallo,
Frage auch für die Deutsch-sprechenden Experten:
Ich hätte auf einer grossen backup-Partition mit mehreren OS-backups gerne jeweils aus dem Unterverzeichnis "Doc&Settings\profilexxx\Local Settings\Temp" den zum Teil dort auftretenden Datenmüll herausgelöscht.
An sich sollte man ja Dateien bloss aus spezifischen Unterverzeichnissen finden und dann gemeinsam bearbeiten - in dem Fall löschen - können.
Die vermeintlich richtige Befehlssyntax <"Local Settings\Temp\" *.*> im Feld "Suche nach" funktioniert aber nicht. Habe auch <*Settings\ Temp\ *.*> und alle möglichen Varianten probiert, ohne Erfolg.
Auch das Beispiel im Hilfefenster <Windows\ system32\ *.ini> funktioniert nur aus dem root und findet dann alle 'inis' in Windows und system32. Was aber, wenn ich nur die 'inis' in sytem32, dafür aber in allen sytem32-Unterverzeichnissen auf allen Partitionen/Laufwerken möchte? Nur <system32\ *.ini> aus dem root geht schon nicht mehr, geschweige denn auf allen Laufwerken.
Weiss jemand Rat? Oder mache ich einen grundsätzlichen (Denk-)fehler? Nur <Temp.> mit Attribut Dir zu suchen ginge zwar, führt aber in meinem Fall zu >180 Temp-Verzeichnissen, ich müsste dann händisch zu jenen in "Local Settings" hinwechseln und alle einzeln löschen - sehr mühsam. Von vornherein "Local Settings\Temp" mit Attribut Dir zu suchen, um wenigstens nur die Temp-Unterverz. von 'Local Settings' zu finden, habe ich auch nicht geschafft.
Danke im Voraus und
mfg
Gerald
Find File in spezifischen Unterverzeichnissen
Moderators: Hacker, Stefan2, white
Hallo,
Ich hätte eine Idee mit einem anderen Ansatz. Die Suche könnte allerdings sehr lange dauern, weil nur im nachhinein gefiltert wird.
Also auf dem Allgemeines-Reiter lässt du "Suchen nach" leer und gibst in "Suchen in" den Startpfad ein (hier wohl "Doc&Settings"). Auf dem Plugins-Reiter gibts du folgende Regel ein:
Ich hätte eine Idee mit einem anderen Ansatz. Die Suche könnte allerdings sehr lange dauern, weil nur im nachhinein gefiltert wird.
Also auf dem Allgemeines-Reiter lässt du "Suchen nach" leer und gibst in "Suchen in" den Startpfad ein (hier wohl "Doc&Settings"). Auf dem Plugins-Reiter gibts du folgende Regel ein:
Code: Select all
plugin.Eigenschaft: tc.Pfad
OP: enthält
Wert: Local Settings\Temp\Hallo,
danke erstmal für die prompte Antwort. Auch für den Tip, wenn sich meine Begeisterung auch in Grenzen hält. Mein Startpfad wäre nämlich das Backup-root (:\-BUP) mit ca. 380GB. Alle Dateien zu suchen (>10^6) und dann zu filtern, da weiss ich jetzt, was man unter "suboptimal" versteht.
Heisst das, ich habe keinen Syntax-Fehler gemacht - und das geht mit FF einfach nicht? Was soll aber dann die include/exclude Dir Eingabe-Option bei "Suche nach"? Oder ist das einfach ein "bug"?
mfg
Gerald
danke erstmal für die prompte Antwort. Auch für den Tip, wenn sich meine Begeisterung auch in Grenzen hält. Mein Startpfad wäre nämlich das Backup-root (:\-BUP) mit ca. 380GB. Alle Dateien zu suchen (>10^6) und dann zu filtern, da weiss ich jetzt, was man unter "suboptimal" versteht.
Heisst das, ich habe keinen Syntax-Fehler gemacht - und das geht mit FF einfach nicht? Was soll aber dann die include/exclude Dir Eingabe-Option bei "Suche nach"? Oder ist das einfach ein "bug"?
mfg
Gerald
Kannst du nicht in mehreren Etappen suchen?
Du führst die Suche immer mit dem Ergebnis der vorherigen Suche weiter.
Startpfad "Doc&Settings"
Du suchst du nach Local Settings (Verzeichnisse) => Anwenden
Du suchst nach Temp. (Verzeichnisse) => Anwenden
Dann hast du alle Temp-Verzeichnisse unterhalb von Local Settings.
Gruß
Du führst die Suche immer mit dem Ergebnis der vorherigen Suche weiter.
Startpfad "Doc&Settings"
Du suchst du nach Local Settings (Verzeichnisse) => Anwenden
Du suchst nach Temp. (Verzeichnisse) => Anwenden
Dann hast du alle Temp-Verzeichnisse unterhalb von Local Settings.
Gruß
2algol
> "Doc&Settings\profilexxx\Local Settings\Temp"
Die Lage der Temp-Ordner ändert sich doch nicht, oder?
Wieso dann jedesmal 'suchen' ?
Wie ich das verstehe reicht doch hier eine Batch aus:
-----------Pseudo Batch.cmd
D:
CD \
CD "Doc&Settings\profilexxx\Local Settings\Temp"
DEL alles
E:
CD \
CD "Doc&Settings\profilexxx\Local Settings\"
RM Temp
MD Temp
F:
CD \
CD "Doc&Settings\profilexxx\Local Settings\Temp"
DEL
-------------------------------------------
Oder muss es unbedingt über die Suchfunktion gehen?
> "Doc&Settings\profilexxx\Local Settings\Temp"
Die Lage der Temp-Ordner ändert sich doch nicht, oder?
Wieso dann jedesmal 'suchen' ?
Wie ich das verstehe reicht doch hier eine Batch aus:
-----------Pseudo Batch.cmd
D:
CD \
CD "Doc&Settings\profilexxx\Local Settings\Temp"
DEL alles
E:
CD \
CD "Doc&Settings\profilexxx\Local Settings\"
RM Temp
MD Temp
F:
CD \
CD "Doc&Settings\profilexxx\Local Settings\Temp"
DEL
-------------------------------------------
Oder muss es unbedingt über die Suchfunktion gehen?
/join #TCMD Chat at irc.freenode.net - Today's newbies are tomorrow's experts.
> ich hatte profilexxx so gedeutet, daß dieses Verzeichnis unterscheidet.
Naja, soooviel Profile wird's ja nicht geben,
und wenn ist's only a matter of copy, paste & edit
-
> Das geht dann wahrscheinlich nur über Suche.
Ich meine die SuFu ist nur nötig wenn das mit dem "Temp" nur ein Beispiel war.
Aber selbst dann würde ich (vll) zuerstmal so vor gehen:
[face=courier]C:\> dir /AD /S | Find "Temp" >C:\DelList.txt[/face]
und dann aus der DelList.txt eine Batch basteln.
Zum Beispiel mit Grep, AWK, bRen oder PSPad...
Lösche Zeilen wie "01.08.2007 12:54 <DIR> Templates"
Search RegEx: [face=courier]^.+<DIR>.+$[/face]
Replace:
Schneide den Rest der Zeilen hinter "Temp" ab
Search RegEx: [face=courier]^(.+)(\\Temp)\\.+$[/face]
Replace: [face=courier]$1$2[/face]
Lösche Zeilen mit "Temporary"
Search RegEx: [face=courier]^(.+)(\\Temp[^\b]).*$[/face]
Replace:
Dann SORT mit Dublikate löschen
und man hat eine schöne Ausgangsbasis für die Batch wie oben erwähnt.
Naja, soooviel Profile wird's ja nicht geben,
und wenn ist's only a matter of copy, paste & edit
-
> Das geht dann wahrscheinlich nur über Suche.
Ich meine die SuFu ist nur nötig wenn das mit dem "Temp" nur ein Beispiel war.
Aber selbst dann würde ich (vll) zuerstmal so vor gehen:
[face=courier]C:\> dir /AD /S | Find "Temp" >C:\DelList.txt[/face]
und dann aus der DelList.txt eine Batch basteln.
Zum Beispiel mit Grep, AWK, bRen oder PSPad...
Lösche Zeilen wie "01.08.2007 12:54 <DIR> Templates"
Search RegEx: [face=courier]^.+<DIR>.+$[/face]
Replace:
Schneide den Rest der Zeilen hinter "Temp" ab
Search RegEx: [face=courier]^(.+)(\\Temp)\\.+$[/face]
Replace: [face=courier]$1$2[/face]
Lösche Zeilen mit "Temporary"
Search RegEx: [face=courier]^(.+)(\\Temp[^\b]).*$[/face]
Replace:
Dann SORT mit Dublikate löschen
und man hat eine schöne Ausgangsbasis für die Batch wie oben erwähnt.
/join #TCMD Chat at irc.freenode.net - Today's newbies are tomorrow's experts.
Danke erstmal für die Tips.
Natürlich war profilexxx nur ein Platzhalter. Da gibt es jeweils 5-7 Profile. Aber noch viel schlimmer ist, dass es etwa 30 kompliziert benannte Instanzen solcher OS-backups unter einem Backup-root gibt.
Wie gesagt, alleine auf dem 2TB-array ca. 400GB. Von den anderen Laufwerksbuchstaben (bis Z: alles vergeben) ganz zu schweigen.
Also nichts mit C:\Doc&Settings. C:\OS, das war mal in den 80ern.
Die gute alte batch-Lösung wäre da eher ein letzter, mühsamer Ausweg, noch dazu, wo einige NTFS-Dateien äusserst lösch-resistent sind.
Aber rein von der Papierform sollte das in TC doch sehr elegant gehen. Wie gesagt, FF Search for: <"Local Settings\Temp\"_space_*.*>. Warum geht das nicht? Unterliege ich hier einem grundsätzlichen Irrtum?
Die Sache mit der abgestuften Suche klingt interessant. Werde ich probieren! Habe aber den Verdacht, dass man FF mit einer expliziten Start-Dir versorgen muss und eine Suche nicht auf ein "feed_to_listbox"-TabFenster anwenden kann. Aber der Gedanke ist gut! Wenn's klappt werde ich berichten!
mfg
Gerald
Natürlich war profilexxx nur ein Platzhalter. Da gibt es jeweils 5-7 Profile. Aber noch viel schlimmer ist, dass es etwa 30 kompliziert benannte Instanzen solcher OS-backups unter einem Backup-root gibt.
Wie gesagt, alleine auf dem 2TB-array ca. 400GB. Von den anderen Laufwerksbuchstaben (bis Z: alles vergeben) ganz zu schweigen.
Also nichts mit C:\Doc&Settings. C:\OS, das war mal in den 80ern.
Die gute alte batch-Lösung wäre da eher ein letzter, mühsamer Ausweg, noch dazu, wo einige NTFS-Dateien äusserst lösch-resistent sind.
Aber rein von der Papierform sollte das in TC doch sehr elegant gehen. Wie gesagt, FF Search for: <"Local Settings\Temp\"_space_*.*>. Warum geht das nicht? Unterliege ich hier einem grundsätzlichen Irrtum?
Die Sache mit der abgestuften Suche klingt interessant. Werde ich probieren! Habe aber den Verdacht, dass man FF mit einer expliziten Start-Dir versorgen muss und eine Suche nicht auf ein "feed_to_listbox"-TabFenster anwenden kann. Aber der Gedanke ist gut! Wenn's klappt werde ich berichten!
mfg
Gerald
Hätte mir vorhin beinahe ins Hemd gemacht!
'Matbal', ich werde dich für den TC_Grossstern in Gold am Blauen Band vorschlagen! Teufel auch, aber das geht! Und es geht so:
Suche im Backup-root nach Doc&Settings, Attr.:Dir
shift-Anwenden/feed-to-listbox->neues Tab mit Resultaten->alle auswählen
Interessanterweise kann man jetzt nicht direkt nach 'Local Settings' suchen, da ja jetzt verschiedene Profil-subdirs kommen und die Suche trotz 'include subdirs - all levels' hier nichts liefert, also die subdirs offenbar nicht mit-einbezieht.
Macht aber nichts!->!Idee!
Suche nach <leer>=alle, markierte Verzeichnisse, Attr.:Dir -> findet nun alle Profile ->shift-anwenden ->in neuem Tab alle auswählen
Suche nach Local Settings, markierte Verzeichnisse, Attr.:Dir -> findet nun ebensoviele Loc.Set.-subdirs -> shift-anwenden -> in neuem Tab alle auswählen.
Aber es kommt noch besser:
Suche nach Temp.(Punkt), Attr.:Dir, liefert jetzt die reinen Temp-Unterverzeichnisse. Wahlweise Suche nach Temp(ohne Punkt) liefert nun auch die 'Temporary Internet Files' dazu (doppelte Verzeichnisanzahl) ->shift-anwenden liefert Tab mit allen Temp-Unterverzeichnissen.
Jetzt aber noch nicht genug!
Suche in allen markierten Verzeichnissen nach <leer>=alles mit Attr.:= nicht Dir -> shift-anwenden
liefert nun ein neues Tab mit genau allen Dateien darin, ohne aber die Dirs selbst.
Nun noch ein wenig nach Grösse sortieren, ein letzter Kontrollblick auf die grösseren, Tausende tmp.-Dateien mit Länge 0 sind ohnehin zu vergessen, und dann grey+/Enter/F8/Enter, bei hidden, read only und dgl. Yes to all, ein Schlückchen Prosecco - und das war's.
TC ist eben doch das tollste Tool, das ich kenne.
Danke nochmal an alle 'Gurus' und Tipgeber hier, allen voran 'Matbal', und
mfg
Gerald
'Matbal', ich werde dich für den TC_Grossstern in Gold am Blauen Band vorschlagen! Teufel auch, aber das geht! Und es geht so:
Suche im Backup-root nach Doc&Settings, Attr.:Dir
shift-Anwenden/feed-to-listbox->neues Tab mit Resultaten->alle auswählen
Interessanterweise kann man jetzt nicht direkt nach 'Local Settings' suchen, da ja jetzt verschiedene Profil-subdirs kommen und die Suche trotz 'include subdirs - all levels' hier nichts liefert, also die subdirs offenbar nicht mit-einbezieht.
Macht aber nichts!->!Idee!
Suche nach <leer>=alle, markierte Verzeichnisse, Attr.:Dir -> findet nun alle Profile ->shift-anwenden ->in neuem Tab alle auswählen
Suche nach Local Settings, markierte Verzeichnisse, Attr.:Dir -> findet nun ebensoviele Loc.Set.-subdirs -> shift-anwenden -> in neuem Tab alle auswählen.
Aber es kommt noch besser:
Suche nach Temp.(Punkt), Attr.:Dir, liefert jetzt die reinen Temp-Unterverzeichnisse. Wahlweise Suche nach Temp(ohne Punkt) liefert nun auch die 'Temporary Internet Files' dazu (doppelte Verzeichnisanzahl) ->shift-anwenden liefert Tab mit allen Temp-Unterverzeichnissen.
Jetzt aber noch nicht genug!
Suche in allen markierten Verzeichnissen nach <leer>=alles mit Attr.:= nicht Dir -> shift-anwenden
liefert nun ein neues Tab mit genau allen Dateien darin, ohne aber die Dirs selbst.
Nun noch ein wenig nach Grösse sortieren, ein letzter Kontrollblick auf die grösseren, Tausende tmp.-Dateien mit Länge 0 sind ohnehin zu vergessen, und dann grey+/Enter/F8/Enter, bei hidden, read only und dgl. Yes to all, ein Schlückchen Prosecco - und das war's.
TC ist eben doch das tollste Tool, das ich kenne.
Danke nochmal an alle 'Gurus' und Tipgeber hier, allen voran 'Matbal', und
mfg
Gerald
Hallo nochmal,
kurzer Nachtrag zu gestern: auch wenn es in der minutiösen Beschreibung umständlich klingen mag, die oben beschriebene Methode funktioniert übrigens beinahe blitzartig trotz riesiger Datenmengen, da die im ersten Schritt gesuchten Verzeichnisse eine verhältnismässig kleine Unterauswahl für die weiteren Suchschritte darstellen.
Nach dem Erfolgserlebnis habe ich nun das Grundproblem etwas genauer analysiert. Frage daher, zuvorderst an Christian himself, ob bug oder feature?
Habe oben beschrieben, dass man nach Doc&Settings nicht unmittelbar nach 'Local Settings' suchen kann sondern zuerst mit <leer> Attr.:Dir alle Profil-Unterverzeichnisse suchen muss.
Warum ist das so? Nun, offenbar werden, zumindest bei Anwendung auf ein Auswahl/Suchlisten-fenster, Dirs nicht in Unterverzeichnissen gesucht, auch wenn man Unterverzeichnisse einschliesst. Ich halte das für einen (kleinen) bug.
Denn genau das ist auch die Ursache dafür, dass im Hilfefenster-Beispiel 'Windows\ system32\ *.ini' nichts mehr gefunden wird, sobald man im root nur 'system32\ *.ini' eingibt (weil man, angenommen, nur die inis in system32 will), denn im root gibt es ja üblicherweise kein system32 subdir. Gibt man aber, wie im Beispiel, vorher Windows\ ein, dann bekommt man auch alle inis im windows-Verzeichnis selbst.
Dieses Verhalten halte ich für ungünstig, führt es doch dazu, dass man bei Suche nach z.B. *.* statt *.ini nun nicht nur alle Dateien in Windows\ selbst findet plus die in system32\, sondern etwa auch alle Dirs in Windows\ angezeigt bekommt, allerdings werden in diesen und unterhalb dann keine Dateien gesucht. Sonst könnte man ja gleich nur *.* oder <leer> eingeben. Das war ja auch mein erster Gedanke, wozu das überhaupt, wenn 'system32\ *.ini' aus dem root nichts findet und 'Windows\ system32\ *.ini' auch die inis in Windows\ findet, warum dann nicht gleich nur *.ini eingeben?
Das include von Directories sucht diese also genau entlang eines (lückenlos) vorgegebenen Pfades und nicht in subdirs.
Besser wäre aber m. E., 'system32\ *.ini' würde inis in allen system32-subdirs unterhalb der gegenwärtigen start-Dir suchen, egal wie tief diese system32-subdirs im Verzeichnisbaum versteckt sein mögen, und zwar nur dort. Wohingegen 'Windows\ system32\ *.ini' bedeuten sollte, dass inis in allen Windows\ und allen system32\ subdirs gefunden werden (sollte es jeweils mehrere geben). Und letztlich sollte 'Windows\system32\ *.ini' (ohne space) nur inis finden, die in system32-subdirs stehen, welche wiederum direkte Unterverzeichnisse von Windows-Verzeichnissen sein müssten.
So wäre es meines Erachtens logisch richtig. Übrigens hätte dann mein "Local Settings\Temp\" *.* Problem, gleichsam als Nebeneffekt, ohne weitere Klimmzüge auch funktioniert.
mfg
Gerald
kurzer Nachtrag zu gestern: auch wenn es in der minutiösen Beschreibung umständlich klingen mag, die oben beschriebene Methode funktioniert übrigens beinahe blitzartig trotz riesiger Datenmengen, da die im ersten Schritt gesuchten Verzeichnisse eine verhältnismässig kleine Unterauswahl für die weiteren Suchschritte darstellen.
Nach dem Erfolgserlebnis habe ich nun das Grundproblem etwas genauer analysiert. Frage daher, zuvorderst an Christian himself, ob bug oder feature?
Habe oben beschrieben, dass man nach Doc&Settings nicht unmittelbar nach 'Local Settings' suchen kann sondern zuerst mit <leer> Attr.:Dir alle Profil-Unterverzeichnisse suchen muss.
Warum ist das so? Nun, offenbar werden, zumindest bei Anwendung auf ein Auswahl/Suchlisten-fenster, Dirs nicht in Unterverzeichnissen gesucht, auch wenn man Unterverzeichnisse einschliesst. Ich halte das für einen (kleinen) bug.
Denn genau das ist auch die Ursache dafür, dass im Hilfefenster-Beispiel 'Windows\ system32\ *.ini' nichts mehr gefunden wird, sobald man im root nur 'system32\ *.ini' eingibt (weil man, angenommen, nur die inis in system32 will), denn im root gibt es ja üblicherweise kein system32 subdir. Gibt man aber, wie im Beispiel, vorher Windows\ ein, dann bekommt man auch alle inis im windows-Verzeichnis selbst.
Dieses Verhalten halte ich für ungünstig, führt es doch dazu, dass man bei Suche nach z.B. *.* statt *.ini nun nicht nur alle Dateien in Windows\ selbst findet plus die in system32\, sondern etwa auch alle Dirs in Windows\ angezeigt bekommt, allerdings werden in diesen und unterhalb dann keine Dateien gesucht. Sonst könnte man ja gleich nur *.* oder <leer> eingeben. Das war ja auch mein erster Gedanke, wozu das überhaupt, wenn 'system32\ *.ini' aus dem root nichts findet und 'Windows\ system32\ *.ini' auch die inis in Windows\ findet, warum dann nicht gleich nur *.ini eingeben?
Das include von Directories sucht diese also genau entlang eines (lückenlos) vorgegebenen Pfades und nicht in subdirs.
Besser wäre aber m. E., 'system32\ *.ini' würde inis in allen system32-subdirs unterhalb der gegenwärtigen start-Dir suchen, egal wie tief diese system32-subdirs im Verzeichnisbaum versteckt sein mögen, und zwar nur dort. Wohingegen 'Windows\ system32\ *.ini' bedeuten sollte, dass inis in allen Windows\ und allen system32\ subdirs gefunden werden (sollte es jeweils mehrere geben). Und letztlich sollte 'Windows\system32\ *.ini' (ohne space) nur inis finden, die in system32-subdirs stehen, welche wiederum direkte Unterverzeichnisse von Windows-Verzeichnissen sein müssten.
So wäre es meines Erachtens logisch richtig. Übrigens hätte dann mein "Local Settings\Temp\" *.* Problem, gleichsam als Nebeneffekt, ohne weitere Klimmzüge auch funktioniert.
mfg
Gerald