Festplattenzugriffe

[Christian Seehase]

Moin Mackhack,

ich habe einmal die Konstante _iFilenameLength angelegt, da diese in der Hauptroutine, als Anzahl Bytes die maximal kopiert werden dürfen, so benötigt wird.
Da das Array aber nur halb soviele Elemente braucht (WChar ist zwei Byte gross), teile ich an der Stelle den Wert durch 2.

SHR ist zwar zum rechnen da, aber das passiert da ja auch

Da beide Werte konstant sind (_iFilenameLength und natürlich die 1) wird dies schon beim compilieren erledigt.

[Mackhack]

Kann mir jemand meine Fragen vom Edit vlt. bitte beantworten. Das laege mir sehr am Herzen das mal zu verstehen...

Vielen Dank!

[Christian Seehase]

Moin Mackhack,

Zitat von Mackhack:

Warum musst du hier das Struct (Record) OVERLAPPED nicht in der Delphi-Unit deklarieren aber das Struct (Record) FILE_NOTIFY_INFORMATION musst du deklariern.

Ich hatte gehofft, dass dies durch die Kommentare in der Demo deutlich geworden ist:
FILE_NOTIFY_INFORMATION musste ich selber deklarieren, da diese Deklaration bei Delphi nicht mitgeliefert wurde, OVERLAPPED hingegen schon (unit Windows).

Zitat von Mackhack:

Das ist etwas im allgemeinen das ich noch nie im Zusammenhang mit der MSDN/API verstanden habe wann ich ein Struct deklarieren muss und wann nicht. Gibt dafuer n einfaches Hint fuer mich und vlt. auch fuer viele/einige andere hier?

Selber deklarieren musst Du alles, was

1. bei Delphi nicht deklariert wurde
2. in einer Form deklariert wurde, die man so nicht gebrauchen kann.
   Beispiel: ExtractIconEx
   Es ist bei Delphi üblich, dass Parameter, die Werte von einer Funktion zurückerhalten als var-Parameter deklariert werden (was es ja in C nicht so gibt). Dies ist auch bei der o.g. Funktion geschehen. Will man nun aber die Liste verarbeiten, die die Funktion normalerweise zurückgibt, klappt das mit der Deklaration nicht, und man muss die Funktion, mit anderer Deklaration, selber importieren (genau für diese Funktion gibt es bei Borland sogar einen Artikel dazu)
3. seit der mitgelieferten Deklaration in Windows aktualisiert (ergänzt) wurde, und von Dir in der aktuellen Version gebraucht wird.
   Beispiel:
   GetOpenFilename bzw. OPENFILENAME-Structure
   In D5 ist nur die "alte" Deklaration enthalten, ohne Placesbar.

Im Allgemeinen wirst Du oft Funktionen / Strukturen selber deklarieren müssen, die es nur unter NT/2000/XP gibt, nicht aber unter 9x/ME, da diese meist nicht vordeklariert sind.
Warum jetzt ReadDirectoryChangesW deklariert wurde, nicht aber die hierfür benötigte Struktur FILE_NOTIFY_INFORMATION müsstest Du bei Borland anfragen (zumindest konnte ich die Deklaration nirgends finden, auch nicht in D2006).

Manche Sachen, die sonst fehlen kannst Du auch woanders finden (vieles z.B. in den Jedis), aber ich verwende da lieber eigene Deklarationen (bei Funktionen), um die Funktionen C-typisch deklariert zu bekommen, also ohne var-Parameter, weil ich es damit leichter habe Beispiele umzusetzen, und mir auch keine Gedanken darum machen muss, ob das mit einem var-Parameter überhaupt wie gewünscht funktioniert (siehe ExtractIconEx).

[Mackhack]

Hallo Christian,

vielen Dank fuer die Erklaerung. Sieht alles schon wesentlich besser aus jetzt

[himitsu]

Also, der Hauptgrund, warum FindFirstChangeNotificationW und ReadDirectoryChangesW zusammen war, lag darin, daß es in dem Code welcher als Vorlage dafür diehnte auch so war.

Und da ReadDirectoryChangesW in dieser Verbindung immer darauf wartet, bis etwas passiert und nicht vorher zurückkehrt (man es also auch nicht beenden konnte), hielt mich natürlich davon ab dieses FindFirstChangeNotificationW zu entfernen, da dort über WaitForSingleObject durch dem Timeout ein Abbruch möglich war ._.
Deshalb wird auch nur wenn etwas da ist (also WaitForSingleObject = WAIT_OBJECT_0) ReadDirectoryChangesW aufgerufen.

Hab inzwischen auch bemerkt, daß bei dir statt dessen CreateIoCompletionPort verwendet wird
und ReadDirectoryChangesW wartet nicht, wenn nichts vorhanden ist.



Find*ChangeNotificationW+WaitForSingleObject und CreateIoCompletionPort sind doch aber "nur" unterschiedliche Methoden, um auf ein Ereignis zu warten.
Da frag ich mich nun aber warum dann ReadDirectoryChangesW unterschiedlich reagiert.


mit Find*ChangeNotificationW+WaitForSingleObject:
-wartet bis zu einem Ereignis (1)
-liefert nur den Dateinamen und kein Verzeichnis
-liefert nur das letzte Ereignis
-manchmal liefert es garnichts und warte auf das nächste Ereignis.

mit CreateIoCompletionPort:
-kehrt immer sofort wieder zurück (1)
-liefert den kompletten Pfad

(1) inwischen geklärt, dat kommt wohl durchs Overlapt.

Zitat:

// Synchron lässt sich der Thread nicht sauber beenden, wenn
// ReadDirectoryChangesW auf die Auslösung des Ereignisses wartet

Läßt er sich schon ... indem man ReadDirectoryChangesW nicht aufruft.



PS: ich seh nichts doppelt.
(zum Test 'ne Datei umbenannt)

Zitat:

X:\USB-Stick\Programme\DirectoryCompareClass.pas
X:\USB-Stick\Programme\DirectoryCompareClass.pas_

Auch nachdem alle Ereignisse überwacht werden ... nicht doppeltes
(FILE_NOTIFY_CHANGE_FILE_NAME or FILE_NOTIFY_CHANGE_DIR_NAME or FILE_NOTIFY_CHANGE_ATTRIBUTES or FILE_NOTIFY_CHANGE_SIZE or FILE_NOTIFY_CHANGE_LAST_WRITE or FILE_NOTIFY_CHANGE_CREATION)

Zitat:

X:\USB-Stick\Programme\DirectoryCompareClass.pas_
X:\USB-Stick\Programme\DirectoryCompareClass.pas
X:\USB-Stick\Programme
X:\USB-Stick\Programme\DirectoryCompareClass.pas

Hab mal 'ne Erweiterung (Angabe der Aktion) drangehängt (beide Änderungen mit {*} am Zeilenanfang gekennzeichnet).
Eventuell liefert das ja eine mögliche Antwort ^^

Zitat:

OLD NAME: X:\USB-Stick\Programme\DirectoryCompareClass.pas_
NEW NAME: X:\USB-Stick\Programme\DirectoryCompareClass.pas
MODIFIED: X:\USB-Stick\Programme
MODIFIED: X:\USB-Stick\Programme\DirectoryCompareClass.pas

[Christian Seehase]

Moin Himitsu,

Zitat von himitsu:

PS: ich seh nichts doppelt.

dann probiere es mal nur mit FILE_NOTIFY_CHANGE_LAST_WRITE.

Zitat von himitsu:

Zitat:

// Synchron lässt sich der Thread nicht sauber beenden, wenn
// ReadDirectoryChangesW auf die Auslösung des Ereignisses wartet

Läßt er sich schon ... indem man ReadDirectoryChangesW nicht aufruft.

Das ist ja ein Wiederspruch in sich, denn wenn man die Funktion nicht aufruft, kann sie natürlich auch nicht hängenbleiben


[EDIT]

Zitat von himitsu:

mit Find*ChangeNotificationW+WaitForSingleObject:
-wartet bis zu einem Ereignis (1)
-liefert nur den Dateinamen und kein Verzeichnis

IMHO liefert Find*ChangeNotification nur die Information dass sich etwas getan hat, aber in keinster Weise welche Datei/Verzeichnis davon betroffen sind (mal abgesehen davon, dass man ja wissen sollte, was man überwacht )

Zitat von himitsu:

mit CreateIoCompletionPort:
-kehrt immer sofort wieder zurück (1)
-liefert den kompletten Pfad

Es wird der Pfad relativ zum überwachten zurückgegeben, aber nicht der komplette Pfad.
[/EDIT]

[himitsu]

Zitat von Christian Seehase:

Das ist ja ein Wiederspruch in sich, denn wenn man die Funktion nicht aufruft, kann sie natürlich auch nicht hängenbleiben

Aber es funktioniert
Also erst mit irgendwas anderem prüfen ob es überhaupt was gibt und nur wenn was vorhanden ist, dann dieses abfragen

Zitat von Christian Seehase:

IMHO liefert Find*ChangeNotification nur die Information dass sich etwas getan hat, aber in keinster Weise welche Datei/Verzeichnis davon betroffen sind (mal abgesehen davon, dass man ja wissen sollte, was man überwacht )

Darum ist es doch nett, man prüft damit ob was da ist und kann dann in gutem Gewissen ReadDirectoryChangesW aufrufen

Is aber erstmal raus, ohne und asynchron läuft es ja auch ganz nett ^^

Zitat von Christian Seehase:

Es wird der Pfad relativ zum überwachten zurückgegeben, aber nicht der komplette Pfad.

Mein ich ja , halt den kompletten Pfad, ab da wo man sucht (is mir auch recht so, weil ich den sonst erst wieder entfernen müßte)

[Christian Seehase]

Moin Himitsu,

Zitat von himitsu:

Darum ist es doch nett, man prüft damit ob was da ist und kann dann in gutem Gewissen ReadDirectoryChangesW aufrufen

Aber wenn Find*ChangeNotification eine Änderung festgestellt hat, wird ReadDirectoryChangesW nicht die gleiche Veränderung feststellen können, da das Ereignis ja schon eingetreten ist, bevor die Funktion aufgerufen wurde.

[himitsu]

Na das würde auch eines der Probleme damit erklären, aber die Idee stammt zum Glück nicht von mir und wandert dennoch fröhlich um die Welt
ReadDirectoryChangesW FindFirstChangeNotification

[Christian Seehase]

Moin Himitsu,

da es bei den beiden Suchbegriffen reichlich Fundstellen gibt:
Welche Site meinst Du?