Mit den antiquierten Dateisystemen von Windows ist sowas nur per polling (=ressorcenvernichtend) zu lösen.
Zumal ich Windows keine Daten anvertrauen würde die auch nur ansatzweise so wichtig sind, dass sie es wert sind sie auf einen Netzwerkshare zu legen...
Ich habe kürzlich eine Lösung für den bevorstehenden Umzug unseres Fileserves auf Basis von ZFS gebaut, das die Änderung des Verhältnisses zwischen USED und REFER überwacht.
Ist ein einfaches shellscript, das per cron nach dem erstellen des neuen snapshots ausgeführt wird. Die grundlogik ist folgendermaßen:
Z.B. die logische größe des datasets beim letzten snapshot (REFER(oldsnap)) war 8GB. Dazugekommen sind 2GB und 2GB wurden geändert, somit belegt der neue snapshot 4GB (USED(newsnap)) und das dataset ist jetzt 12GB groß (REFER(newsnap)):
10/(12-4) = 1.25
Diesen Wert kann man entweder direkt mit einem fixen Wert vergleichen, oder nochmals für das letzte und vorletzte snapshot berechnen, um das delta der Veränderungen zu überwachen - dadurch kompensiert man auch "frische" datasets, die noch mit relativ hoher Rate befüllt werden oder datasets auf denen eine hohe Änderungsrate normal ist. Man kann noch mehr Iterationen berechnen um einen geglätteten Wert auch für stark wechselnde Arbeitslasten zu bekommen, dabei werden aber auch unerwünschte Ereignisse mitgeglättet und ggf später erkannt - muss man für die jeweilige Umgebung abschätzen und entsprechend umsetzen.
Da die werte von ZFS ohne tatsächliche operation ("suchen") auf den Datenträgern bereitgestellt werden, hat man praktisch keinen overhead und belastet das Dateisystem nicht. Man könnte also auch problemlos im minutenabstand das dataset mit dem/den letzten snapshot abgleichen.
Je nach dem welche Clients auf dem dataset arbeiten, kann man z.b. das aktuelle dataset klonen (->analyse), dann zum letzten "unauffälligen" snapshot zurückrollen und readonly setzen. das wäre mein vorgehen wenn windowskisten darauf rumpfuschen dürfen (stichwort cryptolocker).
So können alle weiter mit dem letzten "known good" status arbeiten, durch readonly kann die verseuchte Kiste nicht wieder Schaden anrichten und über das zurückgehaltene dataset/snapshot kann man herausfinden was los war bzw den client/User identifizieren.
Auch gegen "fatfinger" und angep.sste Mitarbeiter die den Fileserver leerräumen wollen greift dieser Mechanismus.
Man könnte auch über die atime und/oder mtime und auditd was bauen, aber da Windows jede Datei angrabbelt wenn man ein Verzeichnis öffnet (speziell mediendateien wie Bilder), dürfte das recht aufwändig werden und eine erhebliche Last auf den Fileserver und das Dateisystem bringen (modifizierte atime oder mtime = veränderte Metadaten müssen beim snapshot geschrieben werden -> deutlich erhöhter overhead!). Auch gebilde mit "find -mtime" sind extrem teuer und haben einen gewaltigen overhead - das einzig sinnvolle/skalierbare ist der Ansatz auf Dateisystemebene, was aber ein Dateisystem aus dem aktuellen jahrhundert voraussetzt
