Batch Windows-Dateiensuche möglich?

Dankeschön. Ich probiere es gleich.

Zudem ist der Kopiervorgang aber immer noch recht langsam (selbst wenn ich nicht jede Abfrage manuell bestätigen müsste). Bei über 1000 Dateien, die kopiert werden sollen, wird das ewig dauern, bis alles kopiert ist. Ich fürchte, schneller wird es wohl nicht gehen, oder?
 
Marvolo schrieb:
bis alles kopiert ist. Ich fürchte, schneller wird es wohl nicht gehen, oder?
Wie immer bei vielen kleinen Dateien, die vorher auch noch gefunden werden wollen - ist wie der Versuch ein Seil zu schieben. Da läßt sich nicht viel beschleunigen. Ist halt Suche + Kopieren mit Nummerierung bei Mehrfachfunden.

Das dauert dann :). Wie lange würde das von Hand dauern, wäre die Gegenfrage?
 
Wenn ich es manuell machen müsste, müsste ich jeden Eintrag in der Output.txt-Datei sichten, bzw. den Dateinamen kopieren und dann in der Windows Dateien-Suche nach diesem Dateinamen suchen lassen, das Gefundene dann in den gefunden-Ordner kopieren.

Dann zurück zum zweiten Eintrag und dasselbe, etc.

Ich dachte nur, ob die langsame Suche vielleicht am Batch-Protokoll liegt und ob da andere Scripte bzw. Methoden vielleicht nicht schneller wären? Aber da kenne ich mich nicht gut genug mit aus.
 
Gute Frage. Letztlich ist es das Parsen von 2 TXT-Dateien, also Name aus der ersten und dann in der 2. suchen, Ergebnis dann kopieren.

Ob das mit PHP und co. schneller geht ist fraglich.
 
Wenn ich das jetzt abbrechen müsste und dann morgen nochmal weiterlaufen lassen würde, fängt es dann von Neuem an oder macht es da weiter, wo es aufgehört hat?

Wie kann ich verhindern, dass es die Index-Such-Datei dann nicht nochmal komplett neu indiziert anhand der output.txt-Datei. Der Index ist ja mittlerweile komplett, der wird sich jetzt auch nicht mehr ändern.

Es bräuchte also demnach nicht jedes mal wieder frisch indizieren.
 
Er würde momentan von vorn beginnen. Das zu verhindern ist wieder aufwändiger, das erfordert ein Logging.

Müßte mal schauen, was da Sinn ergibt.
 
  • Gefällt mir
Reaktionen: Marvolo
Von vorne wäre jetzt nicht das Problem, vor allem wenn es dann zu aufwändig wird.

Aber es müsste nicht nochmal neu die Index-Datei neu-schreiben. Die verändert sich ja nicht mehr vom Inhalt her, egal, wie oft es von vorne anfängt. Kann man wenigstens das dann verhindern?
 
  • Gefällt mir
Reaktionen: s1ave77
Klar doch, einfach 2 Zeilen stilllegen aka auskommentieren:
Rich (BBCode):
echo off
setlocal EnableExtensions
setlocal EnableDelayedExpansion
pushd "%~dp0"
cd "%~dp0"
:: if exist "search.txt" del /s /q "search.txt" >nul
:: for /r "e:\backup" %%A in (*.*) do echo %%~nA | findstr /l "WA0" 1>nul && echo %%A>>search.txt
for /f "delims=" %%i in (output.txt) do (
    set "count="
    for /f "delims=" %%A in (search.txt) do (
        if "%%~nA"=="%%~ni" (
            set /a count+=1
            if "!count!"=="1" (
                if not exist "e:\gefunden%%~pi" md "e:\gefunden%%~pi"
                copy "%%A" "e:\gefunden%%~pi%%~nxA" /y
            ) else (
                if not exist "e:\gefunden%%~pi" md "e:\gefunden%%~pi"
                copy "%%A" "e:\gefunden%%~pi%%~nA_!count!%%~xA" /y
))))
pause
endlocal
exit

Dann nutzt er immer die vorhandenen search.txt als Index.
 
  • Gefällt mir
Reaktionen: Marvolo
Also festhalten können wir:
es tut, was es soll, nun auch mittlerweile ohne lästige Benutzerabfrage jedes Mal. Vielen Dank für die tatkräftige Hilfe bislang!

Allerdings läuft es halt sehr sehr langsam. Ich hatte gestern Abend dann abgebrochen, um es früh heute Morgen wieder zu beginnen (leider ja dann komplett von Vorne, da es nicht dort weitermachen kann, wo es aufgehört hat) und jetzt läuft es seit knapp 07:30 Uhr schon und hat ca. 130 Dateien (inklusive der doppelten, die ich aber ja größtenteils wieder löschen kann, da ich sie nur in sehr bestimmten Fällen brauche).

Bei ca. 6GB Gesamtgröße des Medienordners befürchte ich, wird das selbst heute Abend noch nicht durch sein mit allen Dateien. Wenn ich dann heute Abend wieder abbrechen muss, weil ich es ungern unbeaufsichtigt über Nacht laufen lassen möchte, fängt es ja morgen dann wieder von vorne an. Das bleibt somit ein Teufelskreis und gelangt nie ans Ziel, es sei denn, ich lass es dann tatsächlich mal über Nacht laufen.

Aber vom Prinzip her ist und tut es genau das, was ich gesucht hatte. Wenn's jetzt noch so schnell wie die Windows-Suche wäre, wär's ein Traum. Aber ich weiß ja, dass diese Batch-Skripte ihre Limitierungen haben...
 
Es wäre interessant zu wissen, welcher Befehl hier so langsam ist. Vielleicht entfernst du mal das "echo off" am Anfang und guckst dann welche Zeilen am längsten brauchen, bzw. wo es hängt. Es muss ja entweder das "if not exists" oder das "copy" sein.
 
Gruselig dass sowas immer noch in Batch gemacht wird, knapp 20 Jahre nach der Einführung von Powershell
 
pizza4ever schrieb:
Gruselig dass sowas immer noch in Batch gemacht wird...

Fühl dich frei, hier gerne dein Wissen zu teilen und eine funktionierende bzw. schnellere Lösung anzubieten... Funktionieren tut es ja, halt nur langsam.
 
  • Gefällt mir
Reaktionen: s1ave77
pizza4ever schrieb:
Du bist spät dran. Wo ist das funktionierende Beispiel-Skript.

Zumal festzuhalten ist, dass PS auch nicht gerade ein Performance-Wunder darstellt :). Zudem stellt CMD in der gegebenen Form keine Anforderungen bzgl Laufzeitumgebungen und Co.

@Marvolo der Prozess ist gerade nicht schnell, sollte aber auch alles finden, was gesucht wird. Geschwindigkeit würde einiges an Komplexität erfordern und auch Fehlerquellen möglich machen.

Frage ist, wie oft das laufen soll und vor allem wie lange ein Durchlauf braucht.
 
Also wie schon mal gesagt, eigentlich muss das alles nur ein einziges Mal durchlaufen. Sobald ich die Dateien habe, wird's auch nicht mehr benötigt.

Ich brauche es ja eigentlich nur, um sicherzustellen, dass der Medienordner vollständig ist, das heißt, dass für jeden einzelnen Eintrag in der WhatsApp-Medientabelle in der Datenbank auch eine physische Datei vorhanden ist.

Die meisten Dateien sind das, aber ich kann die jetzt nicht alle einzeln durchgehen und überprüfen. Deswegen dachte ich, ich lass mir anhand der WA-Pfade einfach sämtliche Dateien kopieren, die es braucht und dann ist der Ordner quasi automatisch vollständig.

Wenns schnell gehen sollte, hätte ich jetzt einfach sämtliche Dateien des Backup-Medienordners in den WA-Ordner kopiert, unabhängig davon, ob sie nun gebraucht werden oder nicht. Damit wäre das Verzeichnis wohl auch vollständig, ist dann aber nicht sehr ökonomisch, da dann mit Sicherheit Dateien mitkopiert werden, die WhatsApp gar nicht benötigt und damit überflüssig sind und auf dem Handyspeicher nur Platz wegnehmen.

Eventuell könnte man das Pferd von hinten aufzäumen und mittels eines Scripts nur JENE Dateien suchen und kopieren lassen, die im Medienordner noch fehlen bzw. nicht vorhanden sind anstatt grundsätzlich ALLE zu kopieren, die WA braucht.

Aber auch hier besteht dann die Gefahr, dass bereits jetzt vielleicht überflüssige Dateien im Medienordner vorhanden sind, die WA am Ende eventuell gar nicht braucht und damit nur unnötig den Speicherplatz vollmachen.
Die sauberste Lösung (was Ökonomie / Speicherplatz angeht) wäre wohl die aktuelle, nämlich ALLES zu kopieren, aber nur das, was anhand der WA-Pfade auch tatsächlich gebraucht wird.
 
  • Gefällt mir
Reaktionen: s1ave77
Man könnte mitloggen lassen, was gefunden wird, allerdings muß diese Liste auch geprüft werden, da stehen wir wieder am Anfang :).

Ich würde es einmal durchlaufen lassen, im Hintergrund. Dann hast du die Ordnerstruktur mit den Dateien und kannst weiterschauen.
 
Das Skript ist in Powershell Trivial

Code:
$datei = Get-Content 'output.txt'
$pfad = 'dein pfad'
$timestamp = get-date -Format FileDateTime
$zielordner = Join-Path $pfad -ChildPath $timestamp
New-Item $zielordner -ItemType Verzeichnis
foreach ($zeile in $datei) {
$folder = Split-Path $zeile
$file = Split-Path $zeile -Leaf
$null = robocopy $folder $zielordner $file
}

und in ps kann man die performance auch ganz einfach tracken und wenn die Bremse das Kopieren von der SD Karte ist (was anhand der mir zur Verfügung stehenden Infos die Bremse sein dürfte) gibts da einige workarounds mit denen man arbeiten kann.
 
  • Gefällt mir
Reaktionen: s1ave77
@pizza4ever In "output.txt" steht aber der Quellpfad nicht drin. Also ein bisschen fehlt bei deinem Skript glaub schon. Im Übrigen kann es (zumindest nach dem, wie ich es verstanden hatte) mehrere Quellpfade/-dateien für eine Zieldatei geben.
Aber ja, ich selbst hätte auch nicht unbedingt Batch gewählt.

Das zeilenweise Einlesen von search.txt für jede Zeile von output.txt (noch dazu ohne Abbruchbedingung) ist nach meiner Vermutung sicherlich recht langsam.
Effizienter würde man output.txt genau 1x durchgehen, search.txt genau 1x und deren Einträge in einer HashMap o.ä. mit dem Base-Dateinamen (also ohne Pfad) als Schlüssel ablegen.

Wäre wahrscheinlich sehr viel flotter. Der Dateiweise Kopiervorgang bleibt natürlich noch. Im Übrigen aber, so wie ich das Verstanden habe, nicht von einer SD-Karte, sondern von einem Netzlaufwerk. (Wenngleich nicht komplett ausgeschlossen ist, dass das eine SD-Karte einbindet, aber unwahrscheinlich ist es nun schon.)
 
  • Gefällt mir
Reaktionen: s1ave77
simpsonsfan schrieb:
Im Übrigen aber, so wie ich das Verstanden habe, nicht von einer SD-Karte, sondern von einem Netzlaufwerk.

Mittlerweile nicht mehr Netzwerklaufwerk, sondern externe USB-Festplatte, die aber USB 3.0 kann. Sowohl Quelle der Mediendateien wie auch Ziel der dann rauskopierten/gefundenen liegen nun beide auf der externen Platte mit dem Buchstaben E:\
 
simpsonsfan schrieb:
Effizienter würde man output.txt genau 1x durchgehen, search.txt genau 1x und deren Einträge in einer HashMap o.ä. mit dem Base-Dateinamen (also ohne Pfad) als Schlüssel ablegen.
Für eine einmalige Durchführung leider nur bedingt praktikabel :).

Und ja das PS-Skript berücksichtigt nicht alle geforderten Dinge.
 
simpsonsfan schrieb:
@pizza4ever In "output.txt" steht aber der Quellpfad nicht drin. Also ein bisschen fehlt bei deinem Skript glaub schon. Im Übrigen kann es (zumindest nach dem, wie ich es verstanden hatte) mehrere Quellpfade/-dateien für eine Zieldatei geben.
Aber ja, ich selbst hätte auch nicht unbedingt Batch gewählt.

Das zeilenweise Einlesen von search.txt für jede Zeile von output.txt (noch dazu ohne Abbruchbedingung) ist nach meiner Vermutung sicherlich recht langsam.
Effizienter würde man output.txt genau 1x durchgehen, search.txt genau 1x und deren Einträge in einer HashMap o.ä. mit dem Base-Dateinamen (also ohne Pfad) als Schlüssel ablegen.

Wäre wahrscheinlich sehr viel flotter. Der Dateiweise Kopiervorgang bleibt natürlich noch. Im Übrigen aber, so wie ich das Verstanden habe, nicht von einer SD-Karte, sondern von einem Netzlaufwerk. (Wenngleich nicht komplett ausgeschlossen ist, dass das eine SD-Karte einbindet, aber unwahrscheinlich ist es nun schon.)

von dem search.txt steht im Ursprungspost aber nichts, habe mir nicht alle 4 Seiten durchgelesen. Die search.txt kommt erst in Seite2 irgendwie rein, ohne aber dass ich die genaue Erklärung gefunden hätte.

In solchen Fällen wäre ein komplettes Minimalbeispiel interessant.

Wenn Dubletten vorkommen können, müsste man das Beispiel halt minimal anpassen (wobei das mit robocopy auch kein Problem wäre, da robocopy das quasi verlustfrei handelt)

sehe gerade folgenden Absatz

"Gesucht werden soll logischerweise nicht der gesamte in der TXT-Datei abgebildete Pfad, sondern lediglich der Dateiname (beginnend nach dem allerletzten / im Dateipfad)."

Das ist auf jeden Fall Split Path https://learn.microsoft.com/de-de/p...ell.management/split-path?view=powershell-7.4 bzw. System IO https://learn.microsoft.com/de-de/dotnet/api/system.io?view=net-8.0

Ich halte Batch nach wie vor für eine furchtbare Wahl für alles seit 2015

"Das zeilenweise Einlesen von search.txt für jede Zeile von output.txt (noch dazu ohne Abbruchbedingung) ist nach meiner Vermutung sicherlich recht langsam."

Und ja das ist auf jeden Fall eine Performance Bremse und die gewählte Lösung ist richtig (bzw moderner wäre wohl ein dictionary, ist halt die Frage ob man es braucht.
 
Zuletzt bearbeitet:

Ähnliche Themen

Zurück
Oben