465000 JPGs in einem einzigen Ordner ...

Vorgeschichte:
Habe für jemanden Daten von dessen Festplatte gerettet, mittels Photorec.
Anschließend mit PhotoRec_Sorter.au3 die Dateien nach Endung sortiert.
Resultat: Rund 20 Ordner, prall gefüllt mit den jeweiligen Dateitypen.

Das große Problemkind ist der JPG-Ordner. Dieser beinhaltet über 465000 Bilder (und um Witzen vorzubeugen: nix Porno, sondern Fotograf).
Mein eigentlicher Wunsch wäre, diese abdertausenden Bilder zunächst mal nach Kameramodell sotiert in Unterordner zu verschieben und dann, in einem zweiten Schritt, für jeden Aufnahmetag je einen Unterordner zu erstellen und die Bilder anhand dessen dorthin zu verschieben.

OK, ich wäre schon genügend glücklich über allein nur den letzten Schritt. Also auf die Sortierung nach Kameramodell könnte ich husten, wenn es gelingt, einfach nur die Bilder nach Datum der Aufnahme in Unterordner zu verfrachten, gemäß dem Schema:
2008-03-19
2008-03-20
2009-02-30
...

Der Explorer meiner ollen XP-Kiste rödelt ewig, wenn ich versuche den dicken Ordner zu öffnen. Ich habe auch schon Tools von Heise.de heruntergeladen, die dazu dienen sollen, Dateien automatisch zu sortieren/verschieben. Aber auch damit gab es Probleme, in Form von Hängern. Es sind wohl einfach gar zu viele Dateien im Ordner.

Sicher könnte ich jetzt ein eigenes Script schreiben für diesen Job, an dem ich aber vermutlich tagelang sitzen würde, bis es funzt. Etwas viel Arbeit, für nur einmalige Anwendung und für lau. Der Fotograf will eigentlich nur mal schnell auf bestimmte Bilder zugreifen können, ohne viel Zirkus. So wie es jetzt ist, nützt ihm meine Datenrettung "goa nix".
Das Problem dürfte doch sooo exotisch nicht sein und es muss ja auch gar nicht mal unbedingt per AutoIt geschehen.
Kennt vielleicht jemand ein real funktionierendes Tool für so einen Job, oder hat zufällig jemand ein halbwegs mundfertiges Script zur Hand?

Die kleine Erschwernis liegt halt darin, dass nicht das Filedatum interessant ist, für die Sortierung, sondern das tatsächliche Aufnahmedatum des Bildes. Da müssen wohl die EXIF-Daten ausgewertet werden.
Wie ich bereits weiß, gibt es ein UDF für den Zugriff auf EXIF-Daten.

Wer weiß Rat?

Es muss ja einen Grund geben, warum sich die von mir ausprobierten Tools aufhängten. Jedenfalls werte ich ein zweistündiges Festhängen des Fortschrittbalkens mal als Aufhänger.

Mein Ansatz für ein Script wäre daher der, die Dateien einzeln auf den EXIF-Inhalt abzuklopfen und unmittelbar zu verschieben. Existiert der Zielordner noch nicht, wir er angelegt.
Bei dieser Methode könnte man das Script jederzeit abbrechen und später neu starten; was bis dahin bereits abgearbeitet wurde, ist dann auch definitiv abgearbeitet.

Tools hingegem, die bevor sie etwas verschieben zunächst mal fröhlich die EXIF-Daten aller Dateien auswerten, haben noch rein gar nichts erledigt, wenn sie sich noch vor dem Verschieben verschlucken.

Und warum ich tagelang brauchen würde? - Weil ich mit AutoIt noch nicht so fit bin, wie Ihr.
Der Fotograf will unbedingt morgen seine Festplatten abholen, trotzdem ich ihm sagte, dass ich noch an der Sortierung hänge. Bis morgen bekomme ich kein Tool gebacken - das lehrt meine Erfahrung mit anderen Scripten, wo auch dauernd scheinbare Kleinigkeiten in stundenlangen, am Ende tagelangen Kampf ausarteten.

Oh, ich habe gerade einen echten Durchbruch geschafft. Ich glaube, ich bekomme doch noch ein Script fertig, in den nächsten Stunden.
Das Ergebnis werde ich dann hier posten.
Vielen Dank schon mal an alle, die sich (laut oder leise) 'nen Kopf gemacht haben!

Erfolg!
Habe (wider eigenem Erwarten) erfreulich schmerzfrei ein Script hinbekommen und soeben mit 1000 Bildern getestet, die anstandslos in die automatisch angelegten Zielordner verschoben wurden.
Bilder ohne Aufnahmedatum im EXIF landen dabei in einem gesonderten Ordner.

Ich mache das Script nun noch hübsch und poste es im Anschluss.

Hier nun das einsatzbereite Script:

; Scriptname: PhotoRec-Butler
; Version: 1.0 vom 26.07.'16
; Autor: Stefan Denk (alias "Code-Jack", alias "Desi"), Fa. EDV-Dompteur
; Website: http://www.EDV-Dompteur.de
; Status: Freeware


; V E R W E N D U N G S Z W E C K :
; Dieses Script kommt zur Anwendung nach einer Datenrettung mit dem Programm "PhotoRec", aus dem Programmpaket "Testdisc",
; der ein Durchlauf des Scriptes "PhotoRec_Sorter" folgte.
; Im Anschluss an die Anwendung von PhotoRec_Sorter dürfte man einen Ordner namens "JPG" vorfinden, gefüllt mit nichts als massenhaft JPG-Dateien.
; In meinem eigenen Fall enthielt dieser Ordner über 465000 Dateien, was den Windows-Explorer völlig ausbremste. Es war kaum möglich,
; auch nur den Ordnerinhalt anzeigen zu lassen; es waren einfach gar zu viele Dateien darin vorhanden.
; Die Aufgabe des hier vorliegenden Scriptes ist es, die im JPG-Ordner vorhandenen Bilder, nach Aufnahmedatum sortiert, in automatisch angelegte
; Unterordner zu verschieben, so dass im Anschluss für jeden Tag, an dem ein Bild (bzw. mehrere) aufgenommen wurde(n), ein eigener Unterordner existiert.
;
; B E N U T Z U N G:
; Das Script soll sich NEBEN dem Ordner mit dem Namen "JPG" befinden, wenn es gestartet wird (also NICHT dort hinein kopieren!).
; Dann einfach das Script starten und abwarten. Im Anschluss findet man eine Ordnerstruktur nach folgendem Schema vor:
; ...\JPG\15-08-23
; ...\JPG\15-09-18
; ...\JPG\16-01-29
; etc.
; In jedem dieser automatisch angelegten Unterordner befinden sich nur genau jene Bilder, die an dem Tag aufgenommen wurden, der dem Ordnernamen entspricht.
;
; D A N K S A G U N G:
; Der Autor dankt folgenden Usern des großartigen Forums http://www.autoit.de für ihre Tipps, bzw. Code-Schnippsel:
; Simucal - für die Funktion _FileGetProperty, auf der dieses Script aufbaut.
; Oscar - für Codeschnippsel und präzise Hinweise.
; Xorianator - fürs Mitdenken.




#include <FileConstants.au3>
#include <MsgBoxConstants.au3>
#include <WinAPIFiles.au3>


Global $sQuellpfad = @ScriptDir & "\JPG\"
Global $hSearch
Global $sFileWithPath


; Das Handle der ersten Datei im Quellpfad ermitteln.
$hSearch = FileFindFirstFile($sQuellpfad & "*.*")


; Überprüfen, ob obige Suche erfolgreich war.
If $hSearch = -1 Then
  MsgBox($MB_SYSTEMMODAL, "", "Error: No files/directories matched the search pattern.")
  Return False
EndIf


; Assign a Local variable the empty string which will contain the files names found.
Global $sFileName = "", $iResult = 0


While 1
  $sFileName = FileFindNextFile($hSearch)    ; Der Name der jeweils nächsten Datei.
  If @error Then ExitLoop                    ; Wenn keine weitere Datei vorhanden, dann Script beenden.
  ConsoleWrite($sFileName & @CRLF)           ; Dient nur der Kontrolle, ob das Script auch wirklich tätig ist und nicht etw "hängt"  :-)


  $sFileWithPath = $sQuellpfad & $sFileName  ; Der volle Pfad der Datei, samt deren Dateiname.
  $sAufnahmezeitpunkt = _FileGetProperty($sFileWithPath, "Bild aufgenommen am")  ;Das Datum, an dem das Bild tatsächlich aufgenommen wurde.
  ;ConsoleWrite($sAufnahmezeitpunkt & @CRLF) ; Dient nur zum Debuggen, sollte auskommentiert werden.


  $sJahr = StringMid($sAufnahmezeitpunkt, 7, 4)
  $sMonat = StringMid($sAufnahmezeitpunkt, 4, 2)
  $sTag = StringMid($sAufnahmezeitpunkt, 1, 2)


  $sZielpfad = $sQuellpfad & $sJahr & "-" & $sMonat & "-" & $sTag & "\"  ; Hierhin wird die Bilddatei gleich verschoben.
  ;ConsoleWrite($sZielpfad & @CRLF)          ; Dient nur zum Debuggen, sollte auskommentiert werden.


  ; Quelldatei in den neuen Ordner verschieben (Ordner wird automatisch erzeugt, falls noch nicht vorhanden).
  FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_OVERWRITE + $FC_CREATEPATH)


WEnd


; Close the search handle.
FileClose($hSearch)




;===============================================================================
; Function Name.....: _FileGetProperty
; Description.......: Returns a property or all properties for a file.
; Version...........: 1.0.2
; Change Date.......: 05-16-2012
; AutoIt Version....: 3.2.12.1+
; Parameter(s)......: $S_PATH - String containing the file path to return the property from.
;                     $S_PROPERTY - [optional] String containing the name of the property to return. (default = "")
; Requirements(s)...: None
; Return Value(s)...: Success: Returns a string containing the property value.
;                       If $S_PROPERTY is empty, an two-dimensional array is returned:
;                         $av_array[0][0] = Number of properties.
;                         $av_array[1][0] = 1st property name.
;                         $as_array[1][1] = 1st property value.
;                         $av_array[n][0] = nth property name.
;                         $as_array[n][1] = nth property value.
;                     Failure: Returns 0 and sets @error to:
;                       1 = The folder $S_PATH does not exist.
;                       2 = The property $S_PROPERTY does not exist or the array could not be created.
;                       3 = Unable to create the "Shell.Application" object $objShell.
; Author(s).........: - Simucal <Simucal@gmail.com>
;                     - Modified by: Sean Hart <autoit@hartmail.ca>
;                     - Modified by: teh_hahn <sPiTsHiT@gmx.de>
;                     - Modified by: BrewManNH
; URL...............: http://www.autoitscript.com/forum/topic/...property/page__view__findpost_
; Note(s)...........: Modified the script that teh_hahn posted at the above link to include the properties that
;                     Vista and Win 7 include that Windows XP doesn't. Also removed the ReDims for the $av_ret array and
;                     replaced it with a single ReDim after it has found all the properties, this should speed things up.
;===============================================================================
Func _FileGetProperty(Const $S_PATH, Const $S_PROPERTY = "")
    Local Const $objShell = ObjCreate("Shell.Application")
    If @error Then Return SetError(3, 0, 0)
    Local $iPropertyCount = 300 ; arbitrary number used, Windows 7 only returns 289 properties, Windows XP only returns 38 (future proofing)
    If StringLeft($S_PATH, 1) = '"' Then StringTrimLeft($S_PATH, 1) ; deletes any quotes around the path\filename, otherwise will cause errors
    If StringRight($S_PATH, 1) = '"' Then StringTrimRight($S_PATH, 1) ; deletes any quotes around the path\filename, otherwise will cause errors
    If Not FileExists($S_PATH) Then Return SetError(1, 0, 0)
    Local Const $S_FILE = StringTrimLeft($S_PATH, StringInStr($S_PATH, "\", 0, -1))
    Local Const $S_DIR = StringTrimRight($S_PATH, StringLen($S_FILE) + 1)
    Local Const $objFolder = $objShell.NameSpace($S_DIR)
    Local Const $objFolderItem = $objFolder.Parsename($S_FILE)
    If $S_PROPERTY Then
        For $I = 0 To $iPropertyCount
            If $objFolder.GetDetailsOf($objFolder.Items, $I) = $S_PROPERTY Then Return $objFolder.GetDetailsOf($objFolderItem, $I)
        Next
        Return SetError(2, 0, 0)
    EndIf
    Local $av_ret[300][2] = [[1]]
    For $I = 1 To $iPropertyCount + 1
        If $objFolder.GetDetailsOf($objFolder.Items, $I) Then
            $av_ret[$I][0] = $objFolder.GetDetailsOf($objFolder.Items, $I - 1)
            $av_ret[$I][1] = $objFolder.GetDetailsOf($objFolderItem, $I - 1)
            $av_ret[0][0] += 1
        EndIf
    Next
    ReDim $av_ret[$av_ret[0][0] + 1][2]
    If Not $av_ret[1][0] Then Return SetError(2, 0, 0)
    Return $av_ret
EndFunc   ;==>_FileGetProperty

Mir ist bewusst, dass man da noch einiges optimieren könnte, aber mir reicht es so.
- Vielen Dank noch mal an alle, die dazu beigetragen, oder auch nur mitgedacht haben!

Fataler Fehler,

habe also stundenlang mein Script laufen lassen. Dabei hat sich zwischendrin eigenständig die USB-Platte abgemeldet, auf der die Aktion durchgeführt wurde (warum auch immer).
Ungefähr die Hälfte der Dateien waren bis dahin bereits sortiert.
Schulterzuckend das Script ein zweites Mal gestartet. Als alles fertig war, fand ich etliche leere Ordner vor und die Gesamtanzahl der Dateien betrug nur noch rund 274000 ...

Theorie 1:
Die folgende Zeile:
FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_OVERWRITE + $FC_CREATEPATH)
sollte vielleicht besser so aussehen:
FileMove($sFileWithPath, $sZielpfad & $sFileName, $FC_CREATEPATH)
Also nix Overwrite. Overwrite wird hier ja gar nicht benötigt, weil die von PhotoRec geretteten Dateien ohnehin einen individuell einzigartigen Dateinamen haben.

Habe eben noch mal das Script mit der geänderten Zeile ausprobiert, an 2000 Dateien. Zwischendrin schoss ich gezielt das Script ab und startete es neu. Dabei ist kein Fehler aufgetreten. Nix leere Ordner und identische Anzahl Dateien wie vor der ersten Ausführung.

Theorie 2:
Die Windows-Option "Laufwerk für schnelle Dateisuche indizieren" war aktiviert.
Eventuell hat sich Windows daran irgendwie verschluckt, dass während des Indizierens dauernd Dateien verschoben wurden.

Theorie 3:
Vielleicht war es auch nicht gut, dass der Windows-Papierkorb so konfiguriert war, dass er nur maximal 10% des Laufwerkplatzes verwendet.
Ich hatte ja die Hoffnung, die verschwundenen Dateien im Papierkorb zu finden, aber darin war nur ein Teil vorhanden.

Nun muss ich armer Wicht also die ganze Datenrettung wiederholen. Drei Tage im Stück hatte der Kram gedauert!

Ich werde das Script doch noch etwas aufpolieren, so mit GUI und numerischer Anzeige der bereits bearbeiteten Dateien, statt dem simplen ConsoleWrite($sFileName & @CRLF).
Wer noch gute Ideen hat, gerne her damit!

Zitat von autoBert

Für lau muß er nehmen was er bekommt, sprich sich selber hinsetzen und die Dateien manuel verschieben. Besser 465.000 unsortierte Bilder als gar keine.

Das mit "lau" war nur die vereinfachte Wahrheit.
Der Fotograf beauftragte mich mit der Datenrettung gegen Bezahlung. Ich machte ihm einen sehr günstigen Preis, weil ich es für keine hohe Kunst hielt, Photorec zu starten und den Rechner 1-3 Tage laufen zu lassen.
Womit ich aber nicht gerechnet hatte, das war die enorme Anzahl an Dateien.
Bei meinen früheren Erfahrungen mit PhotoRec kamen immer nur wenige tausend Bilder zusammen; eine Anzahl, die der Windows-Explorer noch problemlos bewältigte.
Der Ordner mit 465000 Bildern hingegen, war in dieser Form komplett unbrauchbar. Da kann man nicht mal manuell Dateien verschieben. Windows rödelt schon minutenlang, wenn man den Ordner nur in Listenansicht öffnen will und drinnen liegt alles chaotisch durcheinander, mit kryptischem Dateinamen vor.

Ich mag es generell nicht, nach einer Preisvereinbarung die Forderung wegen "unerwarteter Schwierigkeiten" zu erhöhen. Lieber nehme ich so etwas auf meine eigene Kappe.
So gesehen war es "für lau". Alle Zusatzarbeit, die mir das bescherte, ist unbezahlt.
Aber natürlich hat der Fotograf den geringen Obolus abzudrücken, der vorab vereinbart war. Und natürlich geht er dann davon aus, anschließend auch einen Nutzen von der Aktion zu haben. Da kann ich ihm keinen Chaos-Ordner mit 465000 wild durcheinander gewürfelten Dateien präsentieren, an dem sich Windows überhebt.

Der Zielpfad enthält ja ganz rechts den Backslash (siehe die aktive Zeile über filemove).

Msgbox ist recht hinderlich, wenn sie oft kommt. Daher hatte ich während der Entwicklung die Consolewriteline drin, um zu sehen, ob die Pfade auch stimmig zusammengesetzt wurden.
Die Pfade stimmen schon, da fehlt kein Backslash oder so.

Getestet an 2000 Dateien entstehen ordnungsgemäß einige Ordner und in jedem befinden sich auch genau die Bilder, die an jenem Tag aufgenommen wurden.

Zitat von Oscar

1. Den Ziel-Dateinamen auch entsprechend den EXIF-Daten erstellen nach folgendem Muster: "JJJJ-MM-TT___HH-MM-SS_(C).jpg"
Wobei man aufpassen muss, dass in der Sekunde evtl. auch mehrere Bilder gemacht worden sind, deswegen der Counter "(C)".

Ja, macht Sinn.
Ist zwar relaiv unnötig, schließlich kann Windows auch nach Aufnahmedatum sortieren, wenn man es entsprechend konfiguriert, aber mit einem Dateinamen nach deinem Vorschlag muss dazu nichts konfiguriert werden, das macht die Sache für 'nen DAU komfortabler.

Statt desir vorgeschlagenen Counters nehme einfach den von PhotoRec vergebenen, einzigartigen Dateinamen (sind 8 bis 10 Zeichen), den ich an den Zeitstempel anhänge.
Das dürfte schneller gehen, als vor dem Verschieben zu testen, ob eine gleichnamige Datei schon vorhanden ist und dann 'ne Zählschleife zu starten, bis eine freie Nummer gefunden wurde.

Zitat von Oscar

2. Statt FileMove zu benutzen, lieber FileCopy und die Rückgabe von FileCopy prüfen, wenn erfolgreich, dann FileDelete.
Das ist sicherer als FileMove. Um ganz sicher zu gehen, könntest Du vor dem FileDelete auch ein Verify durchführen. Das ist aber sehr langwierig.

Guter Vorschlag. Zwar trauere ich dann der Einfachheit von Filemove hinterher, das ja auch automatsich den Zielordner erzeugt, aber ich dachte mir sowieso schon, dass es Sinn macht, die Ordner quasi "von Hand" (mit ein paar zeilen Quelltext) zu erzeugen, statt Filemove das erledigen zu lassen.
Einerseits um mehr Kontrolle zu haben, andererseits um jederzeit die Ordnerzahl zu kennen und im GUI anzeigen zu lassen, während das Script arbeitet:

Anzahl erzeugter Ordner: 223
Verschobene Dateien: 275356

So kann man abschätzen, wie lange das Script wohl noch werkeln wird.
Dazu dann noch ein Button zum Pausieren.
Und so wie es gestrickt ist, kann man es auch jederzeit beenden und später neu starten, um den Rest weg zu sortieren. Man muss also nicht stundenlang im Stück den Rechner laufen lassen.

Zitat von Oscar

3. Unbedingt eine Fehlerbehandlung von "_FileGetProperty" einfügen. Wenn ein Bild fehlerhafte EXIF-Daten aufweist, erstellst Du falsche Ordner.

Klingt auch gut.
Ja, es sind ein paar sonderbare Ordner entstanden. Ohne von mir explizit so vorgesehen, landen alle Dateien ohne Zeitstempel in einem Ordner namens "--". Das ist nett, wenngleich unerwartet.
Ein paar Dateien hatten unsinnige Zeitstempel, so dass ulkige Ordnernamen erzeugt wurden. Wobei ich bislang den Eindruck habe, dass das sogar ein angenehmer Effekt ist - so wird man auf die elegante Tour solche Dateien los, die z. B. aus Internet-Surfsessions stammen.
Daher ja mein ursprünglicher Wunsch, zunächst nach Kameramodell zu sortieren und erst dann nach Datum.
So hätte der Fotograf seine eigenen Aufnahmen schön getrennt von allem sonstigen Bildermüll.

Ich werde wohl all Deine Vorschläge berücksichtigen und bedanke mich sehr, für die guten Einwürfe!