FileSystemWatcher vs polling để xem thay đổi tập tin

Tôi cần thiết lập một ứng dụng theo dõi các tệp được tạo trong một thư mục, cả cục bộ hoặc trên ổ đĩa mạng.

Liệu FileSystemWatcherhoặc bỏ phiếu trên một bộ đếm thời gian sẽ là lựa chọn tốt nhất. Tôi đã sử dụng cả hai phương pháp trong quá khứ, nhưng không rộng rãi.

Có vấn đề gì (hiệu suất, độ tin cậy, v.v.) với một trong hai phương pháp?

Tôi đã thấy trình theo dõi hệ thống tập tin thất bại trong môi trường sản xuất và thử nghiệm. Bây giờ tôi coi đó là một sự tiện lợi, nhưng tôi không cho rằng nó đáng tin cậy. Mẫu của tôi đã theo dõi các thay đổi với trình theo dõi hệ thống tệp, nhưng thỉnh thoảng thăm dò để bắt các thay đổi tệp bị thiếu.

Chỉnh sửa: Nếu bạn có UI, bạn cũng có thể cung cấp cho người dùng khả năng "làm mới" để thay đổi thay vì bỏ phiếu. Tôi sẽ kết hợp điều này với một người theo dõi hệ thống tập tin.

Vấn đề lớn nhất tôi gặp phải là thiếu các tệp khi bộ đệm đầy. Dễ dàng như chiếc bánh để sửa chữa - chỉ cần tăng bộ đệm. Hãy nhớ rằng nó chứa tên tệp và sự kiện, vì vậy hãy tăng nó lên số lượng tệp dự kiến ​​(dùng thử và lỗi). Nó không sử dụng bộ nhớ không thể phân trang, vì vậy nó có thể buộc các quá trình khác chuyển sang trang nếu bộ nhớ thấp.

Đây là bài viết MSDN về bộ đệm: FileSystemWatcher .. ::. InternalBufferSize Thuộc tính

Mỗi MSDN:

Tăng kích thước bộ đệm là tốn kém, vì nó xuất phát từ bộ nhớ không phân trang không thể hoán đổi ra đĩa, vì vậy hãy giữ bộ đệm càng nhỏ càng tốt. Để tránh tràn bộ đệm, hãy sử dụng các thuộc tính NotifyFilter và gộpSubdirectories để lọc các thông báo thay đổi không mong muốn.

Chúng tôi sử dụng 16MB do một lô lớn dự kiến ​​cùng một lúc. Hoạt động tốt và không bao giờ bỏ lỡ một tập tin.

Chúng tôi cũng đọc tất cả các tệp trước khi bắt đầu xử lý ngay cả một ... lấy tên tệp được lưu trữ an toàn (trong trường hợp của chúng tôi, vào bảng cơ sở dữ liệu) sau đó xử lý chúng.

Đối với các sự cố khóa tệp, tôi tạo ra một quá trình chờ đợi để mở khóa tệp trong một giây, sau đó hai, rồi bốn, et cetera. Chúng tôi không bao giờ thăm dò ý kiến. Điều này đã được sản xuất mà không có lỗi trong khoảng hai năm.

Cũng FileSystemWatchercó thể bỏ lỡ các thay đổi trong thời gian bận rộn, nếu số lượng thay đổi được xếp hàng vượt quá bộ đệm được cung cấp. Đây không phải là giới hạn của lớp .NET mỗi lần, mà là cơ sở hạ tầng Win32 bên dưới. Theo kinh nghiệm của chúng tôi, cách tốt nhất để giảm thiểu vấn đề này là loại bỏ các thông báo càng nhanh càng tốt và xử lý chúng trên một chủ đề khác.

Như được đề cập bởi @ChillTemp ở trên, trình theo dõi có thể không hoạt động trên các cổ phiếu không phải của Windows. Ví dụ, nó hoàn toàn không hoạt động trên các ổ Novell được gắn.

Tôi đồng ý rằng một thỏa hiệp tốt là thực hiện một cuộc thăm dò không thường xuyên để nhận bất kỳ thay đổi bị bỏ lỡ.

Cũng lưu ý rằng trình theo dõi hệ thống tệp không đáng tin cậy về chia sẻ tệp. Đặc biệt nếu chia sẻ tệp được lưu trữ trên một máy chủ không có cửa sổ. FSW không nên được sử dụng cho bất cứ điều gì quan trọng. Hoặc nên được sử dụng với một cuộc thăm dò không thường xuyên để xác minh rằng nó đã không bỏ sót điều gì.

Cá nhân tôi đã sử dụng FileSystemWatcherhệ thống sản xuất và nó hoạt động tốt. Trong 6 tháng qua, nó không có một trục trặc nào chạy 24x7. Nó đang theo dõi một thư mục cục bộ duy nhất (được chia sẻ). Chúng tôi có một số lượng hoạt động tệp tương đối nhỏ mà nó phải xử lý (10 sự kiện được thực hiện mỗi ngày). Đó không phải là điều tôi từng phải lo lắng. Tôi sẽ sử dụng nó một lần nữa nếu tôi phải làm lại quyết định.

Tôi hiện đang sử dụng FileSystemWatcher tệp XML được cập nhật trung bình cứ sau 100 mili giây.

Tôi đã thấy rằng miễn FileSystemWatcherlà cấu hình đúng, bạn sẽ không bao giờ gặp vấn đề với cục bộ tệp .

Tôi không có kinh nghiệm về xem tập tin từ xa và chia sẻ không phải Windows.

Tôi sẽ coi việc bỏ phiếu là không cần thiết và không đáng để chi trả trừ khi bạn không tin tưởng FileSystemWatcherhoặc đã trực tiếp gặp phải những hạn chế mà mọi người khác ở đây đã liệt kê (chia sẻ không phải Windows và xem tệp từ xa).

Tôi sẽ đi bỏ phiếu.

Sự cố mạng khiến FileSystemWatcherkhông đáng tin cậy (ngay cả khi quá tải sự kiện lỗi).

Tôi đã gặp rắc rối khi sử dụng FileSystemWatchertrên các chia sẻ mạng. Nếu bạn đang ở trong một môi trường Windows thuần túy, đó có thể không phải là vấn đề, nhưng tôi đã xem một chia sẻ NFS và vì NFS không trạng thái, nên không bao giờ có thông báo khi tệp tôi đang xem thay đổi.

Tôi gặp một số vấn đề lớn với FSW trên các ổ đĩa mạng: Xóa một tệp luôn gây ra sự kiện lỗi, không bao giờ là sự kiện bị xóa. Tôi không tìm thấy giải pháp, vì vậy bây giờ tôi tránh FSW và sử dụng bỏ phiếu.

Mặt khác, các sự kiện tạo hoạt động tốt, vì vậy nếu bạn chỉ cần xem để tạo tệp, bạn có thể đi đến FSW.

Ngoài ra, tôi không có vấn đề gì với các thư mục cục bộ, bất kể có chia sẻ hay không.

Trở về từ phương thức sự kiện càng nhanh càng tốt, sử dụng một luồng khác, đã giải quyết vấn đề cho tôi:

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

Sử dụng cả FSW và bỏ phiếu là một sự lãng phí thời gian và tài nguyên, theo tôi, và tôi ngạc nhiên khi các nhà phát triển có kinh nghiệm đề xuất nó. Nếu bạn cần sử dụng bỏ phiếu để kiểm tra bất kỳ "lỗi FSW" nào, thì bạn có thể loại bỏ hoàn toàn FSW và chỉ sử dụng bỏ phiếu.

Tôi hiện đang cố gắng quyết định xem tôi sẽ sử dụng FSW hay bỏ phiếu cho dự án mà tôi phát triển. Đọc câu trả lời, rõ ràng có những trường hợp mà FSW đáp ứng nhu cầu một cách hoàn hảo, trong khi những lần khác, bạn cần bỏ phiếu. Thật không may, không có câu trả lời nào thực sự xử lý sự khác biệt về hiệu suất (nếu có), chỉ với các vấn đề "độ tin cậy". Có ai có thể trả lời một phần của câu hỏi không?

EDIT: quan điểm của nmclean về tính hợp lệ của việc sử dụng cả FSW và bỏ phiếu (bạn có thể đọc thảo luận trong các bình luận, nếu bạn quan tâm) dường như là một lời giải thích rất hợp lý tại sao có thể có tình huống sử dụng cả FSW và bỏ phiếu là Có hiệu quả. Cảm ơn bạn đã làm sáng tỏ điều đó cho tôi (và bất cứ ai khác có cùng quan điểm), nmclean .

Giải pháp làm việc để làm việc với tạo sự kiện thay vì thay đổi

Ngay cả để sao chép, cắt, dán, di chuyển.

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
                {
                }          
        }
}

Giải pháp cho trình xem tệp này trong khi sự kiện thay đổi thuộc tính tệp bằng cách sử dụng bộ nhớ tĩnh

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;
    }
}

Đây là một giải pháp khắc phục cho vấn đề nhiều sự kiện kích hoạt này.

Tôi sẽ nói rằng sử dụng bỏ phiếu, đặc biệt là trong kịch bản TDD, vì việc giả lập / loại bỏ sự hiện diện của các tệp dễ dàng hơn nhiều hoặc khi sự kiện bỏ phiếu được kích hoạt hơn là dựa vào sự kiện fsw "không kiểm soát" hơn. + đã làm việc trên một số ứng dụng bị lỗi bởi các lỗi fsw.