Zdarzenie Create jest wywoływane również wówczas, gdy utworzony został nowy folder - uważaj na to. Ja osobiście próbowałbym rozwiązać problem inaczej, korzystając z pewnego charakterystycznego zachowania FileSystemWatcher - po zdarzeniu Created wywoływane jest przynajmniej raz zdarzenie Changed. Niestety nie da się przewidzieć, ile takich zdarzeń wystąpi podczas tworzenia pliku, można natomiast w metodzie obsługi zdarzenia Created podpiąć się pod zdarzenie Changed i w nim sprawdzać, czy plik da się otworzyć, najlepiej żądając prawa dostępu do pliku na wyłączność (tj. wywołując File.Open(ścieżka, FileMode.Open, FileAccess.Read, FileShare.None)). Gdy żądanie zostanie spełnione, można odpiąć handler i wywołać zdarzenie informujące o dostępności pliku.

:) No i nie przeczytam drugiego akapitu :)

No już doczytałem, przerwa spowodowana "Piaskowym Dziadygą"

(...) 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

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 FileSystemWatcherEx 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 Created 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 Attach. Ponieważ tworzymy w niej delegat w oparciu o metodę niestatyczną, jest w nim zapamiętywana referencja do obiektu FileChangedWatcher, dla którego wywołano metodę Attach. Następnie sam delegat jest zapamiętywany przez obiekt FileSystemWatcher. W efekcie do momentu wywołania metody Unattach GC nie może zniszczyć obiektu FileChangedWatcher.

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ę push, wówczas polegamy na zdarzeniach zgłaszanych przez FileSystemWatcher. Jeśli chcemy zastosować strategię pull, 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 FileSystemWatcher 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.