Suchmaske nach FindFirst verändern?

[himitsu]

Das hat insofern damit zu tun, daß die Reihenfolge der Dateien zwar zufällig sortiert und vorallem nicht "statisch" ist.

Bei CD-Laufwerken ist es sortiert, weil die Brennprogramme sortieren
und auf der Festplatte sort meistens der NTFS-FileSystem-Treiber dafür.

Wenn man jetzt aber vor schlimmsten Fall ausgeht, dann ist bei jedem erneuten SuchStart (FindFirst) die Dateiliste in einer anderen Reihenfolge und somit würde dein "Ziel des Programms" nicht ereichbar.
Immerhin hast du es ja für veränderliche Verzeichnisse geplant, wo sich quasi unvorhersehbar die Dateiliste ändern kann.

Am Sichersten arbeitet dennach der Code aus Beitrag #22, obwohl er auch einen kleinen Nachteil hat.
> geänderte/überschiebene und gelöschte+neu_erstellte Dateien werden nicht erkannt.

Dein Code (#23) hat ein/zwei kleine Probleme, z.B.
- wenn die Datei aus Form1.Caption gelöscht wurde
- oder die Dateiliste mal nicht sortiert ist.
In beiden Fällen wäre auch das Suchergebnis nicht sortiert und es könnte auch etwas übersprungen oder mehrfach aufgelistet werden.

[PeterPanino]

Zitat:

Zitat von Fridolin Walther

Und genau da liegst Du falsch. Von einer offensichtlichen Race Condition, die eintritt, wenn neue Einträge hinzukommen während der Iteration, einmal abgesehen, funktioniert Dein Ansatz nur, wenn die Dateiliste die FindFirstFile erstellt bei jedem Aufruf exakt gleich ist - sowohl vom Inhalt her als auch von der Position jedes einzelnen Dateirecords. Das ist aber keineswegs garantiert. Um dies zu garantieren, müsste die Liste nach identischen Kriterien sortiert werden jedes Mal, was aber nicht getan wird.

Nochmals: FindFirst erstellt keine Dateiliste, sondern gibt ein Handle zu einer Suche zurück, die von Windows ausgeführt wird. Und: Die Reihenfolge der Iteration ist nicht deshalb konstant, weil die manifestierte Dateiliste nach einem bestimmten Muster sortiert wäre, sondern weil sie UNSORTIERT ist! Du hast richtig gelesen: "Unsortiert" ist also auch eine definierte Reihenfolge, die sich aus der Reihenfolge der Dateien im Dateisystem ergibt. Wenn eine neue Datei zum Verzeichnis hinzugefügt wird, so wird diese so in diese Reihenfolge eingegliedert, wie es die relevanten Regeln des Dateisystems vorsehen.

Wann glaubst Du, dass es regnet: Wenn es der Wetterbericht meldet oder wenn Du auf der Straße nass wirst? ;-)

[Fridolin Walther]

Zitat:

Zitat von PeterPanino

Nochmals: FindFirst erstellt keine Dateiliste, sondern gibt ein Handle zu einer Suche zurück, die von Windows ausgeführt wird.

Du irrst. FindFirstFile ruft NtQueryDirectoryFile auf. NtQueryDirectoryFile auf der anderen Seite liefert eine Doubly Linked List zurück, über die Du dann im späteren Verlauf mit Hilfe der FindNextFile Funktion iterierst.

Zitat:

Zitat von PeterPanino

Und: Die Reihenfolge der Iteration ist nicht deshalb konstant, weil die manifestierte Dateiliste nach einem bestimmten Muster sortiert wäre, sondern weil sie UNSORTIERT ist! Du hast richtig gelesen: "Unsortiert" ist also auch eine definierte Reihenfolge, die sich aus der Reihenfolge der Dateien im Dateisystem ergibt.

Unsortiert ist eben eine nicht definierte Reihenfolge, da sie sich jederzeit von einem FindFirstFile Call zum nächsten ändern kann. Auch die Aussage daß es sich dabei zwangsläufig um die Reihenfolge der Dateien im Dateisystem handelt stimmt nicht. Schau Dir die Reihenfolge von Dateien innerhalb der MFT an und vergleiche die Ergebnisse von FindFirstFile/FindNextFile auf dem selben NTFS Volume.

[PeterPanino]

Zitat:

Zitat von himitsu

Das hat insofern damit zu tun, daß die Reihenfolge der Dateien zwar zufällig sortiert und vorallem "statisch" ist.

Richtig. In Beitrag #32 habe ich gezeigt, dass dies so ist: Die unsortierte Reihenfolge ist "statisch". Ob du das dann als "Zufällig", "kariert" oder "rosa-getupft" bezeichnest, hängt von deinem Geschmack ab.

Zitat:

Zitat von himitsu

Wenn man jetzt aber vor schlimmsten Fall ausgeht, dann ist bei jedem erneuten SuchStart (FindFirst) die Dateiliste in einer anderen Reihenfolge und somit würde dein "Ziel des Programms" nicht ereichbar.

Dann BEWEISE mir doch, dass dieser Fall eintritt. Nach meinen ausgiebigen Tests ist er noch nie eingetreten und kann gar nicht eintreten, da die unsortierte Reihenfolge der Dateien in einem Verzeichnis nicht durch den Zufall, sondern durch das Dateisystem selbst bestimmt wird.

Zitat:

Zitat von himitsu

Am Sichersten arbeitet dennach der Code aus Beitrag #22, obwohl er auch einen kleinen Nachteil hat.
> geänderte/überschiebene und gelöschte+neu_erstellte Dateien werden nicht erkannt.

Unsinn. Mein Code funktioniert auch, wenn Dateien gelöscht/hinzugefügt werden, dieser nicht. Und dass mein Code unsicher wäre, musst du mir erst beweisen.

Zitat:

Zitat von himitsu

Dein Code (#23) hat ein/zwei kleine Probleme, z.B.
- wenn die Datei aus Form1.Caption gelöscht wurde

Nein, denn in diesem Fall wird der Zweck des Programms ebenso erreicht: Durch alle Dateien des Verzeichnisses iterieren, sodass jede Datei einmal drankommt. Da die geladene Datei gelöscht wurde, kann es keine nächste Datei nach dieser Datei geben - dieser Schluss ist implizit.

Zitat:

Zitat von himitsu

- oder die Dateiliste mal nicht sortiert ist.
In beiden Fällen wäre auch das Suchergebnis nicht sortiert und es könnte auch etwas übersprungen oder mehrfach aufgelistet werden.

Wie ich bereits mehrmals geschrieben habe, ist die unsortierte Reihenfolge statisch. Sie kann deshalb nicht einmal SO unsortiert und ein anderes Mal ANDERS unsortiert sein.

[PeterPanino]

Zitat:

Zitat von Fridolin Walther

Zitat:

Zitat von PeterPanino

Nochmals: FindFirst erstellt keine Dateiliste, sondern gibt ein Handle zu einer Suche zurück, die von Windows ausgeführt wird.

Du irrst. FindFirstFile ruft NtQueryDirectoryFile auf. NtQueryDirectoryFile auf der anderen Seite liefert eine Doubly Linked List zurück, über die Du dann im späteren Verlauf mit Hilfe der FindNextFile Funktion iterierst.

Du hast nur mit anderen Worten umschrieben, was ich bereits gesagt habe. Ob man die erstellte Informationsstruktur als Suche oder oder als Liste bezeichnet, ist in Hinblick auf das Diskussionsthema irrelevant.

Zitat:

Zitat von Fridolin Walther

Unsortiert ist eben eine nicht definierte Reihenfolge, da sie sich jederzeit von einem FindFirstFile Call zum nächsten ändern kann.

Du hast mir das noch immer nicht bewiesen, sondern es nur behauptet.

Zitat:

Zitat von Fridolin Walther

Auch die Aussage daß es sich dabei zwangsläufig um die Reihenfolge der Dateien im Dateisystem handelt stimmt nicht. Schau Dir die Reihenfolge von Dateien innerhalb der MFT an und vergleiche die Ergebnisse von FindFirstFile/FindNextFile auf dem selben NTFS Volume.

Die Anordnung der Dateien innerhalb der MFT ist sehr komplex und wird von mehrschichtigen Regeln bestimmt. Deshalb kann man nicht davon ausgehen, dass die dort erscheinende Reihenfolge mit jener an der Windowsoberfläche übereinstimmt. Aber das ist ja auch gar nicht relevant, weil dadurch die Statik der UNSORTIERTEN Reihenfolge nicht beeinflusst wird.

[Fridolin Walther]

Zitat:

Zitat von PeterPanino

Zitat:

Zitat von Fridolin Walther

Zitat:

Zitat von PeterPanino

Nochmals: FindFirst erstellt keine Dateiliste, sondern gibt ein Handle zu einer Suche zurück, die von Windows ausgeführt wird.

Du irrst. FindFirstFile ruft NtQueryDirectoryFile auf. NtQueryDirectoryFile auf der anderen Seite liefert eine Doubly Linked List zurück, über die Du dann im späteren Verlauf mit Hilfe der FindNextFile Funktion iterierst.

Du hast nur mit anderen Worten umschrieben, was ich bereits gesagt habe. Ob man die erstellte Informationsstruktur als Suche oder oder als Liste bezeichnet, ist in Hinblick auf das Diskussionsthema irrelevant.

Nein, Du hast gesagt: "FindFirst erstellt keine Dateiliste". Und diese Aussage ist schlicht und ergreifend falsch. Sieh es ein. Und es ist eben nicht irrelevant in Hinblick auf das Thema. Da Du nämlich mit jedem FindFirst Call eine neue Liste erstellst, deren Nodes zufällig angeordnet sein können.

Zitat:

Zitat von PeterPanino

Du hast mir das noch immer nicht bewiesen, sondern es nur behauptet.

Ich muss gar nichts beweisen.

Zitat:

Zitat von PeterPanino

Die Anordnung der Dateien innerhalb der MFT ist sehr komplex und wird von mehrschichtigen Regeln bestimmt.

Eigentlich ist die MFT relativ simpel und es gibt auch keine wirklichen mehrschichtigen Regeln. Genau genommen gibt es sogar relativ wenige Regeln was die Anordnung der Dateiinformationen angeht.

Im Endeffekt ist jedwede weitere Unterhaltung sinnbefreit. Himitsu und ich haben Dich auf Deinen Denkfehler hingewiesen. Was Du daraus machst ist Deine Sache.

EOD.

[PeterPanino]

Zitat:

Zitat von Fridolin Walther

Ich muss gar nichts beweisen.

Wenn man eine Behauptung aufstellt, muss man sie beweisen. Das ist die Grundlage der Logik, des Denkens und der Wissenschaft überhaupt. Sonst könnte jeder behaupten, die Erde sei eine Scheibe (oder 1 + 1 = 3), und alle Kinder müssen das dann in der Schule lernen ...

Zitat:

Zitat von Fridolin Walther

Eigentlich ist die MFT relativ simpel und es gibt auch keine wirklichen mehrschichtigen Regeln. Genau genommen gibt es sogar relativ wenige Regeln was die Anordnung der Dateiinformationen angeht.

Man sieht, dass du immer wieder vom Thema ablenkst. Das Thema lautet aber: Funktioniert der Code oder funktioniert er nicht? Antwort: Er funktioniert.

Zitat:

Zitat von Fridolin Walther

EOD.

Ja, ja, so sieht das Ende einer Sackgasse aus ...

[PeterPanino]

Conclusio: Der Denkfehler, den himitsu und Fridolin Walther offensichtlich begangen haben, rührt m.E. daher, dass sie zwei Begriffe miteinander verwechselt haben: UNSORTIERT und ZUFÄLLIG. Das sind Begriffe, die wir durch empirische Erkenntnis in der Alltagserfahrung immer wieder im Zusammenhang erlebt haben und die deshalb in unserem Denken fest aneinander gekettet sind: Wenn etwa der kleine Neffe seine Spielzeugkiste umschmeißt, dann liegen alle Bauklötze UNSORTIERT und in scheinbar ZUFÄLLIGEN Mustern auf dem Boden herum. Nun könnte man allerdings ins Detail gehen und die scheinbar zufällige Anordnung der Bauklötze auf kausale Gesetzmäßigkeiten zurückführen und würden dann schnell erkennen, dass die Anordnung der Bauklötze auf dem Fußboden doch nicht zufällig ist, sondern gut nachvollziehbaren statistischen und physikalischen Gesetzmäßigkeiten folgt, also nicht einem "Zufall" unterliegt, der eigentlich der Chaostheorie vorbehalten bleibt. Nur tun wir das in der Praxis des Alltags eben nicht, und betrachten den Begriff "Zufall" als praktische Handhabe, um damit die Abwesenheit von vordergründig erkennbaren Ordnungsmustern zu beschreiben.

Deshalb besteht die Behebung des besagten Denkfehlers in einem ersten Schritt darin, zu erkennen, dass die Eigenschaft UNSORTIERT zwar die Abwesenheit von bekannten Ordnungsmustern beschreibt (etwa Sortierung nach Datum, Größe, usw.), was aber nicht bedeutet, dass UNSORTIERT die Abwesenheit eines JEGLICHEN anderen Ordnungsprinzips impliziert.

Der zweite Schritt ist die Erkenntnis, dass es eine zufällige Anordnung in einem deterministischen System eines durch logischen Code gesteuerten Computers NICHT gibt! Auch dort, wo uns eine solche Anordnung als zufällig erscheint, kann immer von determinierter Kausalität ausgegangen werden. Das bedeutet, dass Code (also Programm und Betriebssystem), der keine explizit "randomistischen" Komponenten enthält, IMMER zum gleichen Ergebnis führen muss. Aus diesem Grund können die mit FindFirst und FindNext gelieferten Suchergebnisse nicht einmal so und ein anderes Mal anders sortiert sein. Das würde aller Logik entbehren.

Q.E.D.

[himitsu]

Zitat:

vorallem nicht "statisch" ist.

Entschuldige erstmal, aber ich hatte da ein nicht vergessen.

Was deinen Code und sein "aktuelles" Funktionieren angeht.
Du hast diesen nur Quellen getestet, welche "zufälliger" Weise geordnet sind (weil es irgendwer so implementiert hat, obwohl er es nicht müßte) und da es dort funktioniert, stellst du hier die Behauptung auf, daß es dann immer funktionieren muß, welches du damit aber nicht bewiesen ist.
Wir haben nur gesagt, daß es in anderen Fällen nicht funktionieren KÖNNTE (nicht daß es auf jeden Fall nicht geht) und haben dich deshalb auf den Umstand hingewiesen, daß die Eingangsinformationen für deinen Code eben nicht dem "Format" entsprechen MÜSSEN, wie du es beschrieben hast.

Also müßtest du uns beweisen, daß dein Code auch bei entsprechenden Eingangsinformationen funktioniert,
oder du ignorierst es, schreibst einen Hinweis an deinen Code und hoffst, daß die Eingangsinformationen "zufällig" dem Format entsprechen, welches dein Code benötigt um auf jeden Fall richtig zu funktioniert.

Zitat:

Wenn man eine Behauptung aufstellt, muss man sie beweisen.

Wir haben die Behauptung aufgestallt, daß die Eingabeinformationen nicht dem Entsprechen, was du behauptet hast.
- es wird eine interne Liste angelegt > bewiesen
- diese muß nicht geordnet sein > es gibt keine Gegenbeweise, daß es IMMER geordnet/sortiert ist

Dieses Verhalten der aktuellen Treiber stammt daher, daß NTFS und Andere sortieren,
bei FAT stammt es von dem verwenden Speicherformat und bei CDFS liegt es an den sortierenden Schreibprogrammen und dem Speicherformat.
Was aber "exotische" und zukünftige Dateisystemtreiber betrifft, kann man da keine Aussage treffen,
also MUß man vom Schlimmsten ausgehen.
Welches auch der Grund ist, warum ich in meinen Programmen, wo es wichtig ist, bei den Dateilisten selber nochmal eine Sortierung über die zwar aktuell sortierten Listen laufen laß.

[PeterPanino]

Zitat:

Zitat von himitsu

also MUß man vom Schlimmsten ausgehen.

Du meinst also, wenn das RAD bisher seit zehntausenden von Jahren funktioniert hat, heißt das nicht, dass es in 50.000 Jahren immer noch funktionieren wird und wir deshalb auf Räder verzichten sollten? ;-)