Lösungsansatz

Wenn auf einem Dateiserver nun sehr viele Dateien "herumliegen", die schon länger nicht mehr beschrieben wurden und vielleicht sogar aus Compliance-Gründen auch gar nicht mehr verändert werden sollten, dann könnte doch ein Prozess auf dem Server diese Dateien mit einem "Deny Write" für die normalen Benutzerkonten versehen. Wenn später ein Anwender eine Datei wirklich noch einmal ändern möchte, dann kann er diese einfach mit einem neuen Dateinamen, z.B. mit einer Versionsnummer, abspeichern: Aber damit wäre zuverlässig verhindert, dass ein Schadcode diese Dateien löscht oder verschlüsselt. Die Grundfunktion wäre also:

Die Analyse der Dateien hat aber auch gezeigt, dass ich noch einmal nachschauen muss, welchen Zeitstempel ich heranziehe Eine Datei auf einem NTFS-Dateisystem hat drei "Zeiten"

Feld  Beschreibung Werte in der 100.000 Files-Auswertung

CreationTime 

Enthält das Datum, wann die Datei angelegt wurde.

Maximum : 19.12.2015 22:20:24
Minimum : 21.02.2000 16:04:28

LastWriteTimeUTC

Enthält das Datum, wann das letzte Mal schreibend auf die Datei zugegriffen wurde

Maximum : 22.02.2024 21:22:22
Minimum : 31.12.1979 22:00:00

LastAccessTimeUTC

Enthält den letzten lesenden Zugriff auf die Date 

Maximum : 19.12.2015 21:20:29
Minimum : 21.02.2000 15:04:28

EEs ist schon irritierend, wenn Dateien angeblich so weit in die Zukunft oder in der Vergangenheit geändert sein sollen. Leider konnte ich nicht mehr nachvollziehen, warum das der Fall war. Anhand der gefundenen Werte muss man schon noch mal nachschauen, welche Information wie geändert wird. Denn per Software kann auch ein Client das Datum jederzeit ändern und zwar alle Daten. Das ist insbesondere wichtig, wenn eine Datei "kopiert" wird, z.B. wenn ein Consultant eine Datei auf dem Notebook erstellt und bearbeitet hat. Dann ist es schon interessant zu sehen, welche Felder beim COPY mitkommen. Zählt als "CreationDate" und "LastWriteDate" dann der Kopierprozess oder wird das originale Datum übernommen? Was passiert bei Änderungen von Berechtigungen oder beim Restore oder einem VSS-Restore ?

Vorgang CreationTime LastAccessTime LastWriteTime Bemerkung

Datei mit Notepad anlegen

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:20:59:01

Erwartetes Verhalten

Datei mit Notepad schreiben 

20.12.2015:20:59:01 

20.12.2015:20:59:01

220.12.2015:21:05:37

LastWriteTime wird zuverlässig aktualisiert.

Datei mit Notepad erneut lesen

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:21:05:37

Seltsam. LastAccess ändert sich nicht. Ist aber wohl Default seit Win7SP1 durch ein Eintrag "NtfsDisableLastAccessUpdate"

Datei mit "get-content" lesen

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:21:05:37

Auch hier verändert sich nichts.

Datei mit Notepad überschreiben (ohne vorher lesen)

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:21:07:03

Das Überschreiben einer Datei ändert weder CreationTime noch LastAccessTime. Das kannte ich aber schon vorher. Siehe FileSystemTunnel

Datei kopieren

20.12.2015:20:59:01
20.12.2015:21:08:54

20.12.2015:20:59:01
20.12.2015:21:08:54

20.12.2015:21:07:03
20.12.2015:21:07:03

Die neue Datei hat zwar ein neues CreationTime und LastAccessTime aber der Werte von "LastWriteTime" wird von der Quelle übernommen. Das muss ich beachten.

Attribute ändern

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:21:07:03

Änderungen der Datei-Attribute (ReadOnly, Komprimiert, EFS) verändern nicht die Zeitstempel 

NTFS-Rechte anzeigen/ändern

20.12.2015:20:59:01

20.12.2015:20:59:01

20.12.2015:21:07:03

Veränderungen an NTFS-Rechten verändern nicht die Zeitstempel.

Die Testreihe zeigt, dass allein der Verlass auf Last AccessTime nicht ausreichend ist um z.B. frische Kopien korrekt zu behandeln. Das Skript muss auf jeden Fall auch das "CreationTime" und LastWriteTime mit einbeziehen. Beide Daten müssen "alt genug" sein, um die Datei nicht zu früh zu sperren.