Problem z FileSystemWatcher.Created

:) No i nie przeczytam drugiego akapitu :)

@Apl
Po chwili namysłu: do rozwiązania z Created trzeba by było dodać listę aktualnie obserwowanych plików tak, aby zdarzenie AfterCreated nie zostało wywołane dla już istniejącego pliku zmodyfikowanego podczas tworzenia nowego pliku. Coś w stylu:

// watcher_Created:
    _currentlyObservedFiles.Add(e.Name);

// watcher_Changed:
if (_currentlyObservedFiles.Contains(e.Name))
{
    _currentlyObservedFiles.Remove(e.Name);
    OnAfterCreated(e);
}

A co do katalogu zamiast pliku… Do tej chwili byłem przekonany, że zostanie to wychwycone w FileNotFoundException. Okazuje się jednak, że jest wówczas wyrzucany UnauthorizedAccessException. Potem odpowiednio zaktualizuję posta.

[i](…) do rozwiązania z Created trzeba by było dodać listę aktualnie obserwowanych plików tak, aby zdarzenie AfterCreated nie zostało wywołane dla już istniejącego pliku zmodyfikowanego podczas tworzenia nowego pliku[/i]

Niekoniecznie, wystarczy stworzyć prostą klasę:

private class FileChangedWatcher
{
public string FullPath { get; private set; }
public FileSystemWatcherEx FileSystemWatcher { get; private set; }

public FileChangedWatcher(FileSystemWatcherEx watcher, string path)
{
FullPath = path;
FileSystemWatcher = watcher;
}

public void Attach()
{
FileSystemWatcher.Changed += HandleFileChanged;
}

public void Unattach()
{
FileSystemWatcher.Changed -= HandleFileChanged;
}

private void NotifyFileReady()
{
FileSystemWatcher.NotifyFileReady(FullPath);
}

private void HandleFileChanged(object sender, FileSystemEventArgs e)
{
if (e.FullPath == FullPath) {
try {
File.Open(FullPath, FileMode.Open, FileAccess.Read, FileShare.None).Close();
Unattach();
NotifyFileReady();
}
catch (IOException) {
// Nic nie rób.
}
}
}
}

W klasie [b]FileSystemWatcherEx[/b] będziemy potrzebować metody do powiadamiania obiektu o dostępności pliku:

private void NotifyFileReady(string fullPath)
{
string directoryName = Path.GetDirectoryName(fullPath);
string fileName = Path.GetFileName(fullPath);
OnAfterCreated(new FileSystemEventArgs(WatcherChangeTypes.Created, directoryName, fileName));
}

Metodę obsługi zdarzenia [b]Created[/b] implementujemy w ten sposób:

private void HandleFileCreated(object sender, FileSystemEventArgs e)
{
if (File.Exists(e.FullPath)) {
FileSystemWatcherEx watcher = (FileSystemWatcherEx) sender;
FileChangedWatcher w = new FileChangedWatcher(watcher, e.FullPath);
w.Attach();
}
}

W konstruktorze podpinamy ją do odpowiedniego zdarzenia i to już w zasadzie wszystko:

public FileSystemWatcherEx()
{
Created += HandleFileCreated;
}

Praktycznie cały trik sprowadza się do wywołania metody [b]Attach[/b]. Ponieważ tworzymy w niej delegat w oparciu o metodę niestatyczną, jest w nim zapamiętywana referencja do obiektu [b]FileChangedWatcher[/b], dla którego wywołano metodę [b]Attach[/b]. Następnie sam delegat jest zapamiętywany przez obiekt [b]FileSystemWatcher[/b]. W efekcie do momentu wywołania metody [b]Unattach[/b] GC nie może zniszczyć obiektu [b]FileChangedWatcher[/b].

Zaznaczam, że jest to tylko pewna moja koncepcja, która niekoniecznie musi działać (kod nie był testowany, a na blogu nie widzę przycisku "Build All"), ale rozwiązania szukałbym gdzieś w tym kierunku.

Kwestia podejścia, osobiście nie porównałbym tego rozwiązania ani do armaty, ani nawet do karabinu wielkokalibrowego, z którego w finale najnowszej części "Rambo" tytułowy bohater rozwala tabuny birmańskiej piechoty. Obydwa rozwiązania są tego samego kalibru, wszystko zależy od tego, co chcemy osiągnąć. Jeśli chcemy zastosować strategię [i]push[/i], wówczas polegamy na zdarzeniach zgłaszanych przez [b]FileSystemWatcher[/b]. Jeśli chcemy zastosować strategię [i]pull[/i], wówczas stosujemy polling w nowym wątku. Pytanie, którą ze strategii uznajemy w tym przypadku za lepszą?

Jak już zdążyłeś zauważyć, skłaniam się ku rozwiązaniu w modelu push. Główną jego zaletą jest to, że o dostępności pliku zostaniemy poinformowani możliwie najwcześniej, jednocześnie implementacja jest nieskomplikowana. Jako główną wadę można postrzegać to, że jesteśmy ograniczeni przez obiekt [b]FileSystemWatcher[/b] i wszelkie akcje musimy wykonywać pod jego dyktando. Podsumowując, jest to metoda prosta, precyzyjna, efektywna i głupia.

W modelu pull główną zaletą jest swoboda, która pozwala na implementację pewnych inteligentnych zachowań, np. możemy próbkować nierównomiernie, w zależności od tego, ile czasu minęło od rozpoczęcia całego proces. Rozwiązanie to może być skuteczne, lecz pod warunkiem, że jest adaptatywne i/lub dobrze dostrojone. Podsumowując, jest to co prawda metoda inteligentna, lecz równocześnie trudna, nieprecyzyjna i tylko czasami efektywna. Osobiście staram się unikać takiego podejścia, gdyż rzadko trafia się okazja, by naprawdę wykorzystać jego zalety.

@mick:
Kluczowe pojęcia: delegaty (delegates) i zdarzenia (events), tutaj jest art w kontekście C++: http://www.functionx.com/vcnet/topics/delevents.htm . Z kolei (sender, e) => to wyrażenie lambda, nie wiem czy jest w c++ odpowiednik takiej konstrukcji… ale możesz zamiast tego napisać zwykłą metodę która przyjmuje argumenty object sender i EventArgs e.