2010-08-18 10 views
81

Mit dem Linux-Betriebssystem gibt es das Ionotify-Subsystem, das eine Anwendung von Änderungen an das Dateisystem benachrichtigt.Gibt es sowas wie Inotify unter Windows?

Ich bin jedoch hauptsächlich ein Windows-Benutzer, also habe ich mich gefragt, ob es eine ähnliche Betriebssystem-API für die Überwachung von Dateisystemänderungen gibt?

+3

Ich denke nicht, dass solche Fragen off Thema sind. Die Frage fragt nach einer OS-API, die sich von jeder Werkzeug-/Softwarebibliothek stark unterscheidet.Kann sein, dass es anders formuliert sein kann, wie man in einer Windows-Anwendung benachrichtigt wird, wenn bestimmte Datei/Dateien geändert werden. – balki

+0

abgestimmt wieder zu öffnen: Die Frage ist für eine vergleichbare Alternative zu einem bestimmten Betriebssystem-API und figuatively liest mich fragen, wie „Ich kommt aus England bin, wo ich mit einer Gabel zu essen, in Japan welches Utensil verwende ich in ähnlicher Weise " Die akzeptierte Antwort unter Verwendung dieser Analogie ist "benutze Stäbchen". – David

Antwort

1

Ich habe ein wenig gesucht, ich erinnere mich, etwas Ähnliches für Windows gesehen zu haben. Es gibt FileSystemWatcher für .NET. Es ist hauptsächlich für NT oder XP und vorwärts.

10

JNotify oder FileMon von Microsoft.

+7

JNotify war perfekt für mich, weil ich Cross-Plattform-Kompatibilität brauchte. Ich konnte sogar ein einzelnes Bash-Skript schreiben, das in cygwin, mac und linux funktioniert, vorausgesetzt, dass JAVA_HOME korrekt eingestellt ist. Dies war eine große Hilfe beim Debuggen von Problemen auf den Maschinen des Kunden, wenn sie sagten "es löschte meine Datei!" Ich kann mir das Logbuch anschauen und versuchen herauszufinden, wie/wann das passiert ist. – cmyers

+1

FileMon ist jetzt ProcessMonitor- https://technet.microsoft.com/en-us/sysinternals/bb896645 – MECU

38

Wenn Sie .net verwenden, verwenden Sie FileSystemWatcher. Mehr Infos hier: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Wenn Sie mit C, verwenden FindFirstChangeNotification, FindNextChangeNotification, ReadDirectoryChangesW. Mehr Infos hier: http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

Auf OSX, die relevante api ist die fsevents api.

Sie unterscheiden sich alle subtil voneinander, und alle haben fragwürdige Zuverlässigkeit in Randfällen. Im Allgemeinen können Sie nicht auf diese API für eine vollständige Ansicht aller Änderungen in 100% der Zeit verlassen. Die meisten Personen, die das Dateisystem-Monitoring verwenden, kombinieren es mit periodischen Scans, um verlorene oder unvollständige Informationen aus der Push-API zu kompensieren.

+4

Können Sie bitte etwas Zitat auf der „fragwürdige Zuverlässigkeit in Rand Fall für inotify geben? – Pharaun

+15

Wenn ein Verbraucher eines api fs Beobachter ist langsamer bei Veranstaltungen als ein anderer Prozess liest bei erzeugen sie, den Kernel entweder braucht Dateisystem Änderungen in dem anderes zu halten (möglicherweise höhere Priorität) Verfahren oder für unbegrenztes Wachstum des Puffers zu ermöglichen. Puffertiefe des inotify (wie dokumentiert in . die Manpage) durch/proc/sys/fs/inotify/max_queued_events Darüber hinaus kontrolliert, können Sie eine IN_Q_OVERFLOW Benachrichtigung bekommen - das ist gut, aber Sie sind immer noch in einer Situation, links, wo Sie Zeit erneut zu scannen können müssen Zeit – blucz

+0

Aha, richtig, ich habe gerade in der Warteschlange gelesen, ich glaube, dieser Fall hängt davon ab, wie viele Dateien Sie überwachen g und es hängt auch davon ab, ob es kritisch ist, alle Änderungen zu verfolgen oder ob einige übersehen werden können. Aber das ist ein guter Punkt. Danke :) – Pharaun

2

Filesystemwatcher() versuchen, ist unzuverlässig vor allem aufgrund der Tatsache ist, Fehlerpuffer für den Beobachter Umgang es mehr oder weniger unvollständig. Aufgrund fehlender Pfad- und detaillierter Informationen zur Fehlerbehandlung bietet Microsoft keine Möglichkeit, das Arbeitsverzeichnis wiederherzustellen oder manuell abzufragen.

Der JNotify für Windows ist auch unzuverlässig, weil dieser Bug^von win32 abgeleitet ist. JNotify verwendet win32. Also, es ist nicht anders als FileSystemWatcher().

+0

darüber nachzudenken, wie Rollen zu entwerfen diese ‚Geschwindigkeit‘/‚Rasse‘/'overflow' artiges Problem zu lösen, fragte ich mich selbst, wie die Kerne es tat. Interessant. Diese Sache tritt auch bei der Vernetzung und Protokollierung auf. Hat dieses Problem einen Namen? – n611x007

+0

Ja, es ist der Name "Bug". Der Fehler (win32) wurde in jedem von Microsoft bisher erstellten Betriebssystem zurückgelassen. Dies macht jedes Microsoft-Betriebssystem für eine Dateiüberwachungslösung ungeeignet. Sie müssen * nix gehen, um es zu erreichen. Manchmal denke ich, dass sie diesen Pufferüberlauf absichtlich aus Sicherheitsgründen verlassen haben. –

+0

haha ​​.. yeah .. der Name ist absichtlich cludge cludge, so dass das Dateisystem von Microsoft nicht absichtlich beobachtet werden kann. Es ist ein Bug, den sie wegen Sicherheitsbedenken hinterlassen haben. –

8

Ein bisschen spät, aber ...

Windows verfügt über eine Einrichtung ähnlich wie OSX Ereignisse wobei Sie Ereignisse ohne eine App verwendet überwachen können. Das Windows USN Journal speichert alle Dateiänderungen. Jeffrey Richter (Autor von Advanced Windows) schrieb eine terrific article mit Arbeitsproben für MSDN Journal.

MSDN documentation for USN Change Journals.

USN Change Journals sind wahrscheinlich besser, wenn Sie Anwendungen wie Backup-Tools oder Indizes Gebäude sind, die ganze Volumes überwachen müssen.

+0

Ist das USN Journal Art und Weise anders, nicht unter Berufung auf den Buggy Verhalten von 'FileSystemWatcher' vermeiden |' FindFirstChangeNotification' [PhillipBrandonHolmes] (http://stackoverflow.com/users/1084830/) war [gemeint ist] (http: //stackoverflow.com/a/17660295/611007)? – n611x007

+4

Es ist eine Weile her, seit ich damit gearbeitet habe, aber es verwendet nicht FileSystemWatcher oder FindFirstChangeNotification. Ich begann in Go einen Windows-Event-Watcher zu schreiben, der stark auf Jeffery Richters Beispielen basierte. Von dem Test, den ich gemacht habe, ist es felsenfest und vermisst nichts, ähnlich wie fsevents in OS X. Gist ist hier: https://gist.github.com/pkrnjevic/7219861 –