2010-08-18 7 views
81

Con il SO Linux, esiste il sottosistema ionotify che notifica un'applicazione di modifiche al filesystem.C'è qualcosa come inotify su Windows?

Tuttavia, sono principalmente un utente di Windows, quindi mi chiedevo se esiste un'API del sistema operativo simile per il monitoraggio delle modifiche al file system?

+3

Non penso che tali domande siano fuori tema. La domanda richiede un'OS API che è molto diversa da qualsiasi strumento/libreria software.Può essere che possa essere formulato in modo diverso come ricevere notifiche in un'applicazione Windows quando vengono modificati file/file particolari. – balki

+0

Votato per riaprire: La domanda è chiedere un'alternativa comparabile a una specifica API del sistema operativo e mi sembra leggendaria come "Io vengo dall'Inghilterra dove uso una forchetta per mangiare cibo, in Giappone quale utensile uso in modo simile ?" La risposta accettata usando quell'analogia è "usa le bacchette". – David

risposta

1

Ho fatto un po 'di ricerche, mi sembra di ricordare di aver visto qualcosa di simile per Windows. C'è FileSystemWatcher per .NET. È principalmente per NT o XP e avanti.

10

JNotify o FileMon da Microsoft.

+7

JNotify è stato perfetto per me perché avevo bisogno di compatibilità multipiattaforma. Ero persino in grado di scrivere un singolo script bash che funzionava con cygwin, mac e linux presumendo solo che JAVA_HOME fosse impostato correttamente. Questo è stato un grande aiuto per il debug dei problemi sulle macchine del cliente, quando dicono "ha cancellato il mio file!" Posso effettivamente guardare il registro e cercare di capire come/quando è successo. – cmyers

+1

FileMon è ora ProcessMonitor https://technet.microsoft.com/en-us/sysinternals/bb896645 – MECU

38

Se si utilizza .net, utilizzare FileSystemWatcher. Maggiori informazioni qui: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Se stai usando C, utilizzare FindFirstChangeNotification, FindNextChangeNotification, ReadDirectoryChangesW. Maggiori informazioni qui: http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

Su OSX, l'API di riferimento è il fsevents api.

Sono tutti sottilmente diversi l'uno dall'altro e hanno tutti un'affidabilità discutibile nei casi limite. In generale, non è possibile dipendere da queste apis per una visione completa di tutte le modifiche al 100% delle volte. La maggior parte delle persone che usano il monitoraggio del file system lo combinano con scansioni periodiche per compensare la perdita o l'incompletezza delle informazioni dalla push api.

+4

Può per favore fornire una citazione sulla "discutibile affidabilità in caso limite per inotify? – Pharaun

+15

Se un utente di as watcher api è un utente più lento a leggere gli eventi rispetto a qualche altro processo è in fase di generazione, il kernel ha bisogno di contenere modifiche al filesystem nell'altro (possibilmente priorità più alta) processo o consentire una crescita illimitata del buffer. profondità del buffer inotify (come documentato in la pagina man) è controllata da/proc/sys/fs/inotify/max_queued_events. Oltre a questo, si ottiene una notifica IN_Q_OVERFLOW - questa è una buona cosa, ma si rimane ancora in una situazione in cui potrebbe essere necessario eseguire nuovamente la scansione da ora a tempo – blucz

+0

Aha giusto, stavo recentemente leggendo in coda. Penso che questo caso limite dipenda da quanti file si monitora g e dipende anche da se è fondamentale per tenere traccia di tutte le modifiche o se alcune possono essere perse. Ma questo è un buon punto. Grazie :) – Pharaun

2

FileSystemWatcher() non è affidabile principalmente dovuto al fatto che è la gestione degli errori per il buffer Watcher è più o meno incompleto. A causa della mancanza di percorsi e delle informazioni dettagliate sulla gestione degli errori, Microsoft non offre alcun modo per ripristinare o eseguire il polling manuale della directory di lavoro.

JNotify per Windows non è affidabile perché questo errore^deriva da win32. JNotify utilizza win32. Quindi, non è diverso da FileSystemWatcher().

+0

pensando a come progettare i ruoli per risolvere questo problema di "velocità"/"corsa"/"traboccante", mi sono chiesto come sono andate le cose. Interessante. Questa cosa si verifica anche con il networking e la registrazione. Questo problema ha un nome? – n611x007

+0

Sì, il suo nome è "bug". Il bug (win32) è stato lasciato in ogni sistema operativo creato da Microsoft fino ad oggi. Questo rende qualsiasi sistema operativo Microsoft non adatto a una soluzione di tipo di controllo dei file. Devi andare * nix per realizzarlo. A volte penso che abbiano intenzionalmente lasciato questo overflow del buffer per ragioni di sicurezza. –

+0

haha ​​.. sì .. il nome è intenzionale cluster kludge in modo che il file system di Microsoft non possa essere guardato intenzionalmente. È un bug che hanno lasciato a causa di problemi di sicurezza. –

8

Un po 'in ritardo ma ...

Windows ha una struttura simile agli eventi OSX per cui è possibile monitorare gli eventi senza correre un app. Windows USN Journal tiene traccia di tutte le modifiche apportate ai file. Jeffrey Richter (autore di Advanced Windows) ha scritto un terrific article con campioni funzionanti per MSDN Journal.

MSDN documentation for USN Change Journals.

USN Change riviste sono probabilmente meglio se si sta costruendo applicazioni come strumenti di backup o indici che hanno bisogno di monitorare interi volumi.

+0

Il journal USN è molto diverso, fa affidamento su di esso evitando il comportamento bug di 'FileSystemWatcher' |' FindFirstChangeNotification' [PhillipBrandonHolmes] (http://stackoverflow.com/users/1084830/) era [parlando di] (http: //stackoverflow.com/a/17660295/611007)? – n611x007

+4

È passato un po 'di tempo da quando ho lavorato con questo, ma non utilizza FileSystemWatcher o FindFirstChangeNotification. Ho iniziato a scrivere un osservatore di eventi di Windows in Go, basato pesantemente sugli esempi di Jeffery Richter. Dal momento del test che ho fatto, è solido e non manca nulla, simile a fsevents in OS X. Gist è qui: https://gist.github.com/pkrnjevic/7219861 –