FileSystemWatcher für viele Dateien

  • VB.NET

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von Sederic Enders.

    FileSystemWatcher für viele Dateien

    Hi,
    gibt es eine Lösung, wie man einen Art FileSystemWatcher (also irgendwas, was aufpasst, ob bestimmte Dateien verändert, umbenannt, gelöscht werden) für ganz viele Dateien macht, oder muss ich FileSystemWatcher für jede betroffene Datei in ein Array schmeißen.
    Danke
    MSDN
    Es wird ein Pfad überwacht, nicht aber eine Datei.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Dann solltest Du probieren, ein Optimum an Parent-Verzeichnissen zu finden, um mit einer minimalen Anzahl an FSW auszukommen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Wenn die Anzahl der Files einigermaßen abzählbar ist, kannst du für alle zu überwachenden Dateien einen Hardlink in einem zentralen Verzeichnis erstellen und dieses dann mit dem FilesystemWatcher überwachen.
    Was übrigens nicht hilft, ist die Erstellung von Junctions, da diese vom FSW nicht verfolgt werden.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    RodFromGermany schrieb:

    Dann solltest Du probieren, ein Optimum an Parent-Verzeichnissen zu finden, um mit einer minimalen Anzahl an FSW auszukommen.

    Aber werden dann die anderen Dateien nicht auch überwacht?

    petaod schrieb:

    Wenn die Anzahl der Files einigermaßen abzählbar ist, kannst du für alle zu überwachenden Dateien einen Hardlink in einem zentralen Verzeichnis erstellen und dieses dann mit dem FilesystemWatcher überwachen.
    Was übrigens nicht hilft, ist die Erstellung von Junctions, da diese vom FSW nicht verfolgt werden.

    Wie geht das dann?^^
    Also kann ich den Watchfolder löschen, wenn ich das Prog beende
    Um die ganzen Hardlinks beim nächsten Aufruf wieder neu anzulegen?
    Na meinetwegen.

    Auf jeden Fall würde ich erst mal mit Testdaten arbeiten, bevor ich solche Spiele in der Produktionsumgebung mache.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Sry dass ich nochmal frag, aber wie muss das jetzt in vb.net Code heißen:

    petaod schrieb:

    fsutil hardlink create c:\watchfolder\file1.txt c:\anyfolder1\file1.txt
    fsutil hardlink create c:\watchfolder\file2.txt c:\anyfolder2\file2.txt
    usw.


    und außerdem stell ich mich wahrscheinl. grad zu dumm an, weil wenn ich mit

    VB.NET-Quellcode

    1. Private Declare Function CreateHardLink Lib "kernel32.dll" Alias "CreateHardLinkA" (ByVal lpFileName As String, ByVal lpExistingFileName As String, ByRef lpSecurityAttributes As Long) As Long
    2. 'und dann
    3. CreateHardlink(newFile, originalFile, 0)

    den Hardlink erstell, dann verändert sich der Name der einen Datei nicht, wenn ich den anderen änder (was natürlich klar ist). Und der File System Watcher merkt ja auch nicht, wenn ich die ursprüngl. Datei ändere...
    Der obige Code ist kein VB-Code, sondern wird mit der Shell ausgeführt.
    Ich ging davon aus, dass du immer dieselben Dateien überwachen willst und das ein einmaliger Vorgang ist.

    Was willst du denn erreichen? Wenn du die Liste der Dateien sowieso in deinem Programm hast, benötigst du ja keinen Watcher mehr, sondern kannst auch gleich in einem Hintergrundthread ab und zu mal nachsehen, ob sich das ModificationDate oder CreationDate geändert hat.
    Das ist ein anderer Ansatz und wesentlich ressourcenschonender als ein FilesystemWatcher, der ja eigentlich Veränderungen im Verzeichnis überwacht.

    Sederic Enders schrieb:

    der File System Watcher merkt ja auch nicht, wenn ich die ursprüngl. Datei ändere
    Da verhält sich das Filesystem manchmal sehr komisch, weil die Fileinfos, solange der Link nicht angetastet wird, häufig erst verspätet nachgezogen werden.
    Da merkt man mal wieder, dass NTFS halt doch aus einer Krücke entstanden ist.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --