FileSystemWatcher "überreagiert"

10/06/2008 - 14:37 von Marvin Niemann | Report spam
Hallo,

ich hab auf ein Verzeichnis 2 FileSystemWatcher losgelassen.
(mit VS .NET 2005 Standard erstellte C#-Anwendung)

string sWatchPath = <Verzeichnisname>

// regiert auf Änderungen an Verzeichnissen
FileSystemWatcher watchDir = new FileSystemWatcher();
watchDir.Path = sWatchPath;
watchDir.InternalBufferSize = 16384;
watchDir.IncludeSubdirectories = true;
watchDir.NotifyFilter = NotifyFilters.LastWrite |
NotifyFilters.DirectoryName;
watchDir.Filter = "*";

sowie

// regiert auf Änderungen an Dateien
FileSystemWatcher watchFile = new FileSystemWatcher();
watchFile.Path = sWatchPath;
watchFile.InternalBufferSize = 16384;
watchFile.IncludeSubdirectories = true;
watchFile.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName;
watchFile.Filter = "*";

jeweils mit eigenen Handlern für .Delete und .Rename

Das Verzeichnis liegt auf einem Fileserver, auf etwa 5 Nutzern übers LAN
zugreift. Der Watcher-Prozess làuft direkt auf dem Server, beobachtet
also selbst /nicht/ übers Netz.

Als Reaktion auf das Löschen einer Datei vom Typ A lösche ich im
.Delete-Handler eine Datei vom Typ B im selben Verzeichnis. Das Löschen
von B-Dateien behandle ich nicht, d.h. ich verhindere im Handler, dass
es wie eine Löschung von A-Dateien behandelt wird.

Problem: Aus unklarem Grund werden bestimmte B-Dateien gelöscht, obwohl
die zugehörigen A-Dateien noch vorhanden sind.

Der Handler ist (laut Log) fest der Meinung, dass entsprechende
A-Dateien gelöscht wurden.

Auf dem Entwicklungsrechner kann ich das Problem nicht nachstellen, auf
dem Server nicht debuggen.

Wonach kann ich suchen? Kann es sein, dass ein Überschreiben/Neu
abspeichern einer Datei ein .Delete-Ereignis auslöst? Kann ich
vielleicht wenigstens irgendwie rausfinden, welcher Nutzer die A-Datei
(angeblich?) gelöscht hat?

MN
 

Lesen sie die antworten

#1 Thomas Scheidegger
10/06/2008 - 19:23 | Warnen spam
Hallo Marvin

vorab,
das Verhalten des .NET FileSystemWatcher
ist vollumfànglich durch das intern verwendete Win32 API:
ReadDirectoryChangesW (=>MSDN, KB, Google!)
vorgegeben und aus .NET nicht darüber hinaus beeinflussbar!

Wegen NTFS-(Filesystem) -internen Ablàufen
sowie via Netzwerk-Redirector/CIFS
sind die Events 'by design' nicht immer so
wie man es logischerweise erwartet/erhofft.
Generell: man sollte die FSW-Events
eher nur als 'Hinweise' (oder Refresh) verstehen,
aber nicht als absolut exaktes/synchrones Logging.


Kann es sein, dass ein Überschreiben/Neu abspeichern einer Datei ein
.Delete-Ereignis auslöst?



AFAIK ja, je nach App, insbesondere etwa MSOffice
(IMHO nahe an einem Design-Fehler)



Thomas Scheidegger - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/

Ähnliche fragen