Festplattenzugriffe

[Mackhack]

Zitat:

Zitat von Luckie

Es hat sich Gott sei dank erledigt. das Programm wird jetzt über den Taskplaner nachts gestartet oder eben manuell.

Hi Luckie,

ich weis dass du das wohl nicht mehr brauchst aber ich habe 2 interessante Dinge gefunden die dich vlt. (doch) noch interessieren zu deinem damaligen Problem:

Eric Gunnerson's C# Compendium

Und aus der MSDN:

Zitat:

ReadDirectoryChangesW fails with ERROR_INVALID_PARAMETER when the buffer length is greater than 64 KB and the application is monitoring a directory over the network. This is due to a packet size limitation with the underlying file sharing protocols.

Quelle:
ReadDirectoryChangesW

[himitsu]

Das ERROR_INVALID_PARAMETER könnte ein Problem erklären ... ich laß inzwischen den entsprechenden Thread mit erhöhter Priorität laufen und schon geht es, nur kommt jetzt hinzu, daß man nur den Datei-/Verzeichnisnamen bekommt, was bei WatchSubtree=True zu problemen führt, man erfährt leider nicht wo in dem ganzen Verzeichnisbaum die Datei liegt.



Da darf man ja dennoch alles durchsuchen und eindeutiger wird es erst recht nicht, wenn mehrere Dateien mit dem selben Namen existieren.

Praktisch könnte man jetzt zwar für jedes Unterverzeichnis einzeln eine Überwachung einrichten, nur könnte man dann keine Verzeichnisse mehr löschen, da diese ja geöffnet wären. (abgesehen von den Unmassen an Handles und Überwachungsthreads)
Und wenn man eh alles durchsuchen muß, wäre diese ReadDirectoryChangesW doch schon fast nurtzlos.



Zu "Eric Gunnerson's C# Compendium" schön daß man jetzt anscheinend auch noch auf die kurzen Dateinamen achten muß :wall:

[Christian Seehase]

Moin Zusammen,

ich habe hier mal ein Demoprojekt für die asynchrone Verwendung von ReadDirectoryChangesW angehängt.
Das Projekt ist (wie ich denke ;-)) vollständig dokumentiert.

Zwei Punkte noch vorab, auch wenn sie bereits in der Dokumentation stehen:

1. Das Ereignis, das bei einer überwachten Veränderung ausgelöst wird, wird immer zweimal hintereinander mit identischem Ergebnis ausgelöst.
   (einen Thread zur Ursache hatte ich auch schon einmal hier eröffnet: ReadDirectoryChangesW wird mehrfach ausgelöst. Warum?).
   Soweit ich bislang feststellen konnte handelt es sich hierbei im ein Problem der Funktion selber, und ist nicht delphispezifisch.
   
2. Die Pfadangaben die man zurückerhält sind immer relativ zum überwachten Verzeichnis zu sehen.
   Dies muss man immer vor die einzelnen Ergebnisse setzen.

Suchbegriffe, damit in der Demo enthaltene Begriffe über die Suche gefunden werden können:
ReadDirectoryChangesW, CreateIoCompletionPort, GetQueuedCompletionStatus, FILE_NOTIFY_INFORMATION, OVERLAPPED, WC_NO_BEST_FIT_CHARS, FILE_LIST_DIRECTORY

[EDIT]
Fehler in Demo korrigiert
[/EDIT]

[EDIT2]
Demo erneut korriert :oops:
[/EDIT2]

[Mackhack]

Hallo Christian,

vielen Dank fuer das Demo. Musst nur in der Zeile 193

Delphi-Quellcode:

FsResult := FsPath + '\' + FsResult;

den Backslash rausmachen da man sonst Sachen wie C:\\xxxxx bekommt.

Und warum sind im Memo hinter den FileNames immer "???"?

[DGL-luke]

Schau dir mal die windows-registry an, wie viele doppelte backslashes du da drin hast :roll:

das hinzufügen des backslash ist sehr viel einfacher als es durch IncludeTrailingPathDelimiter zu jagen.

[Mackhack]

Zitat:

Zitat von DGL-luke

Schau dir mal die windows-registry an, wie viele doppelte backslashes du da drin hast :roll:

das hinzufügen des backslash ist sehr viel einfacher als es durch IncludeTrailingPathDelimiter zu jagen.

Warum IncludeTrailingPathDelimiter nutzen? Der Backslash den ich meinte ist doch am Anfang!

[Christian Seehase]

Moin Mackhack,

woher die ??? kommen kann ich mir im Moment auch nicht erklären, denn bei mir treten sie nicht auf.
Kannst Du mal ein Beispiel dafür angeben, was Du überwacht hast und mit welchem NotifyFilter?
Ausserdem könnte noch das Betriebssystem wichtig sein.

Den zusätzlichen Backslash hast Du übrigens nur, wenn Du ein Laufwerk angibst. Wenn Du ein Verzeichnis nimmst, tritt das nicht auf.
Für Windows spielt übrigens die Anzahl aufeinanderfolgender Pfadtrennzeichen keine Rolle, sie werden immer als einer gewertet.

[Mackhack]

Hi,

also hier mal die Daten und ein Beispielauszug aus dem Memo.

Windows XP Media Center Edition English SP2
Filter: FILE_NOTIFY_CHANGE_LAST_WRITE
Ueberwachung: C:\
File aus Memo: C:\\Documents and Settings\{USERNAME}\Application Data\{ANWENDUNG}\{ANWENDUNG}.statistics.bak????

[Christian Seehase]

Moin Mackhack,

ich glaube ich habe den Fehler gefunden:

Ein SetLength steht an der falschen Stelle

Delphi-Quellcode:

          // Falsch
          if iLen = 0 then begin
            FsResult := 'ERROR';
          end else begin
            FsResult := FsPath + '\' + FsResult;
            SetLength(FsResult,iLen);
          end;


          // Richtig
          if iLen = 0 then begin
            FsResult := 'ERROR';
          end else begin
            SetLength(FsResult,iLen);
            FsResult := FsPath + '\' + FsResult;
          end;

So 'was Blödes :wall:

Ausserdem habe ich noch etwas gefunden:

Da der Dateiname in der Struktur FILE_NOTIFY_INFORMATION (wFilename) ja vom Typ WChar ist, kann die Längenangabe verkleinert werden:

Delphi-Quellcode:

  FILE_NOTIFY_INFORMATION = packed record
    dwNextEntryOffset : DWORD;
    dwAction          : DWORD;
    dwFileNameLength  : DWORD;
    wFilename         : array [1.._iFilenameLength shr 1] of WCHAR; // shr 1 ist neu
  end;

[EDIT]
Korrgierte Demo hochgeladen
BUG: SetLength in der falschen Zeile
BUG: Länge von wFilename in FILE_NOTIFY_INFORMATION
[/EDIT]

[EDIT2]
Demo erneut korriert :oops:
BUG: Man sollte auch den Buffer für das Ergebnis (FNI) initialisieren :wall:
BUG: Länge von wFilename in FILE_NOTIFY_INFORMATION. Wenn ich durch 2 teilen will sollte ich wohl besser nicht shr 2 nehmen :wall:
[/EDIT2]

[Mackhack]

Zitat:

Zitat von Christian Seehase

Delphi-Quellcode:

    wFilename         : array [1.._iFilenameLength shr 1] of WCHAR; // shr 1 ist neu

Christian, warum nimmst du denn shr um die ArrayLaenge zu bestimmen? Ich dachte shr und shl ist zum rechnen (multiplizieren/dividiren) da.

//Edit:
Darf ich dich hier mal noch fragen was ich dich bereits in meiner PM fragte?
Warum musst du hier das Struct (Record) OVERLAPPED nicht in der Delphi-Unit deklarieren aber das Struct (Record) FILE_NOTIFY_INFORMATION musst du deklariern.

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?