FileSystemWatcher vs polling untuk melihat perubahan file

Saya perlu mengatur aplikasi yang mengawasi file yang dibuat dalam direktori, baik secara lokal maupun pada drive jaringan.

Apakah FileSystemWatcheratau polling pada timer akan menjadi pilihan terbaik. Saya telah menggunakan kedua metode di masa lalu, tetapi tidak secara ekstensif.

Masalah apa (kinerja, keandalan, dll.) Yang ada pada kedua metode tersebut?

Saya telah melihat pengamat sistem file gagal dalam lingkungan produksi dan pengujian. Saya sekarang menganggapnya sebagai kenyamanan, tetapi saya tidak menganggapnya dapat diandalkan. Pola saya adalah untuk melihat perubahan dengan pengamat sistem file, tetapi jajak pendapat sesekali untuk menangkap perubahan file yang hilang.

Sunting: Jika Anda memiliki UI, Anda juga dapat memberi pengguna Anda kemampuan untuk "menyegarkan" untuk perubahan daripada polling. Saya akan menggabungkan ini dengan pengamat sistem file.

Masalah terbesar yang saya miliki adalah file yang hilang ketika buffer sudah penuh. Mudah dipecahkan - cukup tambahkan buffer. Ingat bahwa itu berisi nama file dan peristiwa, jadi tingkatkan ke jumlah file yang diharapkan (coba-coba). Itu memang menggunakan memori yang tidak dapat dihubungi, sehingga bisa memaksa proses lain ke halaman jika memori semakin rendah.

Berikut ini adalah artikel MSDN pada buffer: FileSystemWatcher .. :: .InternBufferSize Property

Per MSDN:

Meningkatkan ukuran buffer mahal, karena berasal dari memori non-paged yang tidak dapat ditukar ke disk, jadi jaga buffer sekecil mungkin. Untuk menghindari buffer overflow, gunakan properti NotifyFilter dan IncludeSubdirectories untuk menyaring pemberitahuan perubahan yang tidak diinginkan.

Kami menggunakan 16MB karena batch besar diharapkan pada satu waktu. Berfungsi dengan baik dan tidak pernah melewatkan file.

Kami juga membaca semua file sebelum mulai memproses bahkan satu ... dapatkan nama file dengan aman di-cache (dalam kasus kami, ke dalam tabel database) kemudian memprosesnya.

Untuk masalah penguncian file, saya menelurkan proses yang menunggu file dibuka kuncinya menunggu satu detik, kemudian dua, kemudian empat, dan sebagainya. Kami tidak pernah polling. Ini telah diproduksi tanpa kesalahan selama sekitar dua tahun.

The FileSystemWatcherjuga mungkin kehilangan perubahan selama sibuk kali, jika jumlah perubahan antri meluap buffer disediakan. Ini bukan batasan dari kelas .NET per se, tetapi dari infrastruktur Win32 yang mendasarinya. Dalam pengalaman kami, cara terbaik untuk meminimalkan masalah ini adalah dengan membagikan pemberitahuan secepat mungkin dan menghadapinya di utas lainnya.

Seperti disebutkan oleh @ChillTemp di atas, pengamat tidak dapat bekerja pada saham non-Windows. Misalnya, itu tidak akan berfungsi sama sekali pada drive Novell yang terpasang.

Saya setuju bahwa kompromi yang baik adalah melakukan jajak pendapat sesekali untuk mengambil setiap perubahan yang terlewat.

Perhatikan juga bahwa pengamat sistem file tidak dapat diandalkan pada berbagi file. Terutama jika berbagi file di-host di server non-windows. FSW tidak boleh digunakan untuk hal-hal penting. Atau harus digunakan dengan jajak pendapat sesekali untuk memverifikasi bahwa ia tidak melewatkan apa pun.

Secara pribadi, saya telah menggunakan FileSystemWatchersistem produksi, dan sudah bekerja dengan baik. Dalam 6 bulan terakhir, itu tidak memiliki cegukan tunggal berjalan 24x7. Ini memantau folder lokal tunggal (yang dibagikan). Kami memiliki sejumlah kecil operasi file yang harus ditangani (10 peristiwa dipecat per hari). Itu bukan sesuatu yang pernah saya khawatirkan. Saya akan menggunakannya lagi jika saya harus membuat kembali keputusan.

Saat ini saya menggunakan FileSystemWatcherpada file XML yang diperbarui rata-rata setiap 100 milidetik.

Saya telah menemukan bahwa selama FileSystemWatcherdikonfigurasi dengan benar Anda seharusnya tidak pernah memiliki masalah dengan file lokal .

Saya tidak punya pengalaman tentang menonton file jarak jauh dan berbagi non-Windows.

Saya akan mempertimbangkan polling file menjadi berlebihan dan tidak sebanding dengan biaya overhead kecuali Anda secara inheren tidak mempercayai FileSystemWatcheratau secara langsung mengalami keterbatasan semua orang di sini telah terdaftar (saham non-Windows, dan menonton file jarak jauh).

Saya akan pergi dengan polling.

Masalah jaringan menyebabkan FileSystemWatchertidak dapat diandalkan (bahkan ketika overloading peristiwa kesalahan).

Saya mengalami masalah saat menggunakan FileSystemWatcherberbagi jaringan. Jika Anda berada di lingkungan Windows murni, itu mungkin tidak menjadi masalah, tapi saya menonton berbagi NFS dan karena NFS tidak memiliki kewarganegaraan, tidak pernah ada pemberitahuan ketika file yang saya tonton berubah.

Saya punya beberapa masalah besar dengan FSW pada drive jaringan: Menghapus file selalu melempar kesalahan, tidak pernah menghapus kejadian. Saya tidak menemukan solusi, jadi saya sekarang menghindari FSW dan menggunakan polling.

Acara penciptaan di sisi lain bekerja dengan baik, jadi jika Anda hanya perlu melihat pembuatan file, Anda dapat menggunakan FSW.

Juga, saya tidak punya masalah sama sekali pada folder lokal, tidak masalah apakah dibagikan atau tidak.

Kembali dari metode acara secepat mungkin, menggunakan utas lain, menyelesaikan masalah untuk saya:

private void Watcher_Created(object sender, FileSystemEventArgs e)
{
    Task.Run(() => MySubmit(e.FullPath));
}

Menggunakan FSW dan polling adalah pemborosan waktu dan sumber daya, menurut pendapat saya, dan saya terkejut bahwa pengembang yang berpengalaman menyarankannya. Jika Anda perlu menggunakan polling untuk memeriksa "ada kesalahan FSW", maka Anda dapat, secara alami, membuang FSW sama sekali dan hanya menggunakan polling.

Saya, saat ini, mencoba untuk memutuskan apakah saya akan menggunakan FSW atau polling untuk proyek yang saya kembangkan. Membaca jawabannya, jelas bahwa ada kasus di mana FSW memenuhi kebutuhan dengan sempurna, sementara di lain waktu, Anda perlu polling. Sayangnya, tidak ada jawaban yang benar-benar berurusan dengan perbedaan kinerja (jika ada), hanya dengan masalah "keandalan". Adakah orang yang bisa menjawab bagian pertanyaan itu?

EDIT: nmclean untuk validitas menggunakan FSW dan polling (Anda dapat membaca diskusi di komentar, jika Anda tertarik) tampaknya menjadi penjelasan yang sangat rasional mengapa mungkin ada situasi yang menggunakan FSW dan polling adalah efisien. Terima kasih telah menjelaskan hal itu untuk saya (dan siapa pun yang memiliki pendapat yang sama), nmclean .

Solusi bekerja untuk bekerja dengan membuat acara alih-alih perubahan

Bahkan untuk menyalin, memotong, menempel, bergerak.

class Program
{        

        static void Main(string[] args)
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";
            FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
            FileSystemWatcher.Path = SourceFolderPath;
            FileSystemWatcher.IncludeSubdirectories = false;
            FileSystemWatcher.NotifyFilter = NotifyFilters.FileName;   // ON FILE NAME FILTER       
            FileSystemWatcher.Filter = "*.txt";         
             FileSystemWatcher.Created +=FileSystemWatcher_Created; // TRIGGERED ONLY FOR FILE GOT CREATED  BY COPY, CUT PASTE, MOVE  
            FileSystemWatcher.EnableRaisingEvents = true;

            Console.Read();
        }     

        static void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
        {           
                string SourceFolderPath = "D:\\SourcePath";
                string DestinationFolderPath = "D:\\DestinationPath";

                try
                {
                    // DO SOMETING LIKE MOVE, COPY, ETC
                    File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
                }
                catch
                {
                }          
        }
}

Solusi untuk pengamat file ini saat acara perubahan atribut file menggunakan penyimpanan statis

class Program
{
    static string IsSameFile = string.Empty;  // USE STATIC FOR TRACKING

    static void Main(string[] args)
    {
         string SourceFolderPath = "D:\\SourcePath";
        string DestinationFolderPath = "D:\\DestinationPath";
        FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
        FileSystemWatcher.Path = SourceFolderPath;
        FileSystemWatcher.IncludeSubdirectories = false;
        FileSystemWatcher.NotifyFilter = NotifyFilters.LastWrite;          
        FileSystemWatcher.Filter = "*.txt";         
        FileSystemWatcher.Changed += FileSystemWatcher_Changed;
        FileSystemWatcher.EnableRaisingEvents = true;

        Console.Read();
    }     

    static void FileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
    {
        if (e.Name == IsSameFile)  //SKIPS ON MULTIPLE TRIGGERS
        {
            return;
        }
        else
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";

            try
            {
                // DO SOMETING LIKE MOVE, COPY, ETC
                File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
            }
            catch
            {
            }
        }
        IsSameFile = e.Name;
    }
}

Ini adalah solusi untuk masalah ini dari berbagai peristiwa pemicu.

Saya akan mengatakan menggunakan polling, terutama dalam skenario TDD, karena jauh lebih mudah untuk mengejek / mematikan keberadaan file atau sebaliknya ketika acara polling dipicu daripada bergantung pada acara fsw yang lebih "tidak terkontrol". + untuk yang telah bekerja pada sejumlah aplikasi yang diganggu oleh kesalahan fsw.