2011-01-31 11 views
5

Sto cercando un modo affidabile per cercare le modifiche in una directory.Modo affidabile di monitorare le modifiche ai file in una directory utilizzando il framework .NET

Ho provato a usare FileSystemWatcher, ma è piuttosto impreciso quando molti piccoli file vengono creati, modificati o cancellati. Manca circa l'1 o 2% dei file nei miei test. Questo è abbastanza quando aggiungi o modifichi rapidamente migliaia di file.

Ho provato a eseguire il polling per le modifiche a intervalli diversi 500 ms, 2000 ms ecc. In questo caso ottengo troppi hit. Questo potrebbe avere qualcosa a che fare con la risoluzione dei timestamp sull'oggetto FileInfo.

Quindi la mia domanda è; è possibile, utilizzando .NET Framework, ottenere le modifiche in una directory in modo affidabile?

- Christian

risposta

7

Hai provato ad aumentare lo InternalBufferSize? A che taglia hai impostato?

Da MSDN:


Nota che un FileSystemWatcher può perdere un evento quando la dimensione del buffer è superato. Per evitare eventi mancanti, seguire queste linee guida: Aumentare la dimensione del buffer impostando la proprietà InternalBufferSize . Evitare guardando file con nomi di file lunghi, perché un nome file lungo contribuisce a a riempire il buffer. Considerare rinominare questi file utilizzando i nomi più corti.


mantenere il codice di gestione degli eventi più breve possibile.

+0

Grazie, questo sembra risolvere i miei problemi per ora. Impossibile far perdere file con un buffer di 64 KB, è necessario eseguire un paio di test per trovare le impostazioni ottimali. –

4

Sì, un adeguato monitoraggio viene eseguita utilizzando driver di filtro del file system. Tale driver intercetta tutte le richieste che arrivano al filesystem quando vengono inviate (prima o dopo che raggiungono il filesystem). In questo modo si ottengono tutte le notifiche, giusto nel tempo (o anche prima che si verifichi l'evento) e si può controllare quali richieste passano e quali informazioni vengono trasmesse con la richiesta.

È possibile scrivere tale driver di filtro da soli (~ 6-9 minuti-uomo di lavoro per implementarlo correttamente e quindi molto tempo per il test) oppure è possibile utilizzare il nostro prodotto CallbackFilter ed evitare lo sviluppo in modalità kernel. CallbackFilter offre un driver e API preconfigurati per .NET, VCL e C++ nativo.

+1

Grazie per il suggerimento Eugene, in realtà ho cercato il tuo CallbackFilt prima di cercare un progetto che è stato scartato. Questo è un progetto per hobby quindi ho bisogno di mantenerlo semplice per ora. Ma ti terremo a mente;) –

+3

@Eugene: questa risposta è stata contrassegnata come spam da un paio di utenti. Non sono convinto che lo sia, perché (nonostante non sia un esperto nel settore) sembra che il tuo prodotto in realtà * non * fornisca una soluzione al problema. Tuttavia, in futuro potresti voler considerare di rendere un po 'più ovvio che stai promuovendo il tuo prodotto. Forse un disclaimer in fondo o qualcosa del genere. E +1 per contrastare i downvotes. –

+1

@Cody Gray - la frase "il nostro ... prodotto" insieme al nome utente lo dice abbastanza chiaramente, come per me, e questo è stato affrontato prima (entrambi discussi su Meta e testati qui) e accettati. –

Problemi correlati