kleines Kopiertool für Fotos

Das hat nichts mit der Platte zu tun Musashi.

Die Geschwindigkeit bricht (auf dem jeweiligen Niveau der Platte) bei kleinen Dateien unter Windows immer ein.

Zitat von autoiter

Die Geschwindigkeit bricht (auf dem jeweiligen Niveau der Platte) bei kleinen Dateien unter Windows immer ein.

Das weiß ich, nur merkt man es auf dem Niveau z.B. deiner SSD halt nicht (so stark).

Gruß Musashi

Naja, bei wenigen Dateien schon. Aber hier geht es um ein Kopiertool. Da sollte man schon von vielen Dateien ausgehen..

EDIT: blondi@ Hast du die neue Version von _FileCopyEx? Oscar hat deinen Wunsch umgesetzt. Nimm meinen ersten Code, nimm die neue UDF und passe die Parameter an. Schreib dann nochmal, ob es ein Geschwindigkeitsproblem gibt. Wenn nicht, muss Musashi nochmal nachbessern.

Haha, da hatte ich bisher gar nicht detailliert eingeschaut. Danke für die Aufklärung, Oscar

Hi autoiter !

Dass es beim Kopieren vieler Dateien zu Geschwindigkeitseinbrüchen seitens Windows kommt, ist unzweifelhaft. Eine schnelle Platte kann hier aber einiges kaschieren .

Von welchen Dateimengen wir bei blondi@ reden, teilt Sie uns ggf. ja noch mit.

Zitat von Oscar

Wenn Quelle und Ziel auf der gleichen Partition liegen ist Copy und Delete sehr langsam im Vergleich zu FileMove.

Gut zu wissen .

Jetzt wo ich kurz darüber nachgedacht habe ja auch völlig logisch.

Zitat von autoiter

Wenn nicht, muss Musashi nochmal nachbessern.

Ich werde eh mal eine Variante mit FileMove und einer großen Dateimenge machen - rein schon aus Eigeninteresse . Letztlich liegt es an der Geschwindigkeit der AutoIt-Funktionen im Allgemeinen, nicht an meinem Tool im Besonderen. Wenn Du z.B. FileCopy und FileDelete verwendest, wird es ja nicht schneller.

Gruß Musashi

P.S. : Meine Güte, es rauschen z.Zt. aber viele Beiträge 'rein. Da kommt man mit dem Tippen ja kaum hinterher

Zitat von Musashi

Letztlich liegt es an der Geschwindigkeit der AutoIt-Funktionen im Allgemeinen, nicht an meinem Tool im Besonderen. Wenn Du z.B. FileCopy und FileDelete verwendest, wird es ja nicht schneller.

Zitat von Oscar

Wenn Quelle und Ziel auf der gleichen Partition liegen ist Copy und Delete sehr langsam im Vergleich zu FileMove.

Na, eben doch. Es geht darum, wie du die Funktionen in deinem Skript nutzt.

Zitat von blondi@

solange die auf der gleichen Platte liegen.

solange sie auf der selben Partition liegen.

blondi@

Dann nehme ich die CheckBox kopierte .cr2-Datei(en) im Quellordner löschen heraus.

Es wird immer mit FileMove gearbeitet, d.h. die cr2. Dateien werden aus dem Quellordner verschoben.

Die Option bestehende .cr2-Datei(en) überschreiben (Ja/Nein - also im Zielordner) lasse ich aber 'drin !

Ist das so OK ?

Gruß Musashi

Hallo blondi@ !

Hier die neue Version mit FileMove. Ich habe die Dateinamen entsprechend geändert, sie heißen jetzt :

- BlondisFileMoveV4.au3

- Filemove.ini (statt Filecopy.ini) -> Funktion ist aber gleich

(sind enthalten in der angehängten zip-Datei BlondisFileMoveV4.zip)

Du kannst ja mal posten, wieviel Zeit jetzt benötigt wird - eine Timerangabe wird am Ende angezeigt .

EDIT : blondi@

Neue Version : Prüfung hinzugefügt (am 12.01.2019)

Wenn im Zielordner KEINE *.jpg-Dateien vorhanden sind, kommt jetzt eine kleine Meldung !

Gruß Musashi

Zitat von Oscar

Das gilt aber nur, wenn Quelle und Ziel auf der gleichen Partition liegen.

blondi@ !

Das stimmt !

Dein derzeitiger Arbeitsablauf findet aber auf einer Partition statt. Darauf ist das kleine Hilfstool z.Zt. eingerichtet und soll keinen Filemanager ersetzen (*.cr2 und *.jpg machen es ja eh schon speziell). Funktionieren tut es in beiden Fällen, bei unterschiedlichen Partitionen dauert es nur länger.

Ich kann das gemäß Oscars Anregung aber gerne erweitern, also :

Quellpartition = Zielpartition ==> FileMove (schneller)

Quellpartition <> Zielpartition ==> FileCopy / FileDelete (schneller)

Ist keine große Sache, obwohl Du es möglicherweise gar nicht brauchst .

Gruß Musashi

Hallo Musashi

Zitat von Musashi

Quellpartition <> Zielpartition ==> FileCopy / FileDelete (schneller)

Warum sollte das schneller sein? Ich denke FileMove tut es immer.

Zitat von autoiter

Warum sollte das schneller sein? Ich denke FileMove tut es immer.

Meine Vermutung wäre, dass beim FileMove die Dateien nach dem Verschieben direkt gelöscht werden, das reduziert die Geschwindigkeit, da die Platte nicht am Stück verschiebt.

Liegen die Daten unfragmentiert hintereinander ist es viel einfacher im Dateisystem einfach alle gleichzeitig zu löschen (einfach den entsprechenden Bereich als gelöscht markieren) als alle Bereiche separat zu löschen.

Das macht sich selbstverständlich nur bei vielen Dateien und nicht bei wenigen großen Dateien bemerkbar.

//Edit, ich hab das Tool nicht gesehen aber ich vermute mal es löscht die Daten direkt? Dann gilt meine Vermutung natürlich nur wenn man im Nachhinein alles löscht.

Beim FileMove auf der selben Platte sollte das ganze offensichtlich sein, dass es schneller ist, denn die Dateien werden nicht verschoben, sondern es wird im Dateisystem (je nach Dateisystem, FAT, NTFS, inodes) einfach nur die Dateipointer restrukturiert anstatt erstmal alles zu duplizieren und dann zu löschen.

Zitat von autoiter

Warum sollte das schneller sein? Ich denke FileMove tut es immer.

FileMove tut es auch immer , es geht um den Zeitverbrauch bei identischer bzw. unterschiedlichen Partition(en). Oscar 's Zitat :

Zitat

Function FileMove

If the source and destination paths are on different volumes a copy and delete operation is performed rather than a move.

stammt aus der Hilfe. Das habe ich häufiger aber auch an anderen Stellen bereits gelesen.

Das Ganze ist wohl mehr eine Frage der Vollständigkeit. Blondi@ hat ihre Arbeitsweise ja klar beschrieben, und da sind verschiedene Partitionen der Ausnahmefall. Natürlich kann man alles verbessern, erweitern ... ad nauseam.

Gruß Musashi