Cách giữ ReadDirectoryChangesW khỏi các thay đổi tệp bị thiếu

Question

Có nhiều bài đăng trên internet về chức năng API ReadDirectoryChangesW thiếu tệp khi có nhiều hoạt động tệp. Hầu hết đổ lỗi cho tốc độ mà tại đó vòng lặp chức năng ReadDirectoryChangesW được gọi. Đây là một giả định không chính xác. Lời giải thích tốt nhất mà tôi đã thấy là trong các bài sau đây, nhận xét về thứ hai 14 tháng 4, 2008 14:15:27

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/

Bản tóm tắt là báo cáo chức năng ReadDirectoryChangesW nộp thay đổi khi chúng rời khỏi hàng đợi tập tin-ghi-đằng sau, không phải khi chúng được thêm vào. Và nếu quá nhiều được thêm trước khi được cam kết, bạn sẽ mất thông báo về một số trong số đó. Bạn có thể thấy điều này với việc triển khai của mình, nếu bạn chỉ viết một chương trình để tạo ra 1000 tệp trong một thư mục thật nhanh. Chỉ cần đếm có bao nhiêu thông báo sự kiện tập tin bạn nhận được và bạn sẽ thấy có những lúc bạn sẽ không nhận được tất cả chúng.

Câu hỏi đặt ra là, có ai đã tìm thấy phương pháp đáng tin cậy để sử dụng chức năng ReadDirectoryChangesW mà không phải xóa âm lượng mỗi lần không? Điều này không được phép nếu người dùng không phải là Quản trị viên và cũng có thể mất chút thời gian để hoàn thành.

Answer 1

Nếu API không đáng tin cậy, thì giải pháp thay thế có thể là lựa chọn duy nhất của bạn. Điều đó tất nhiên có khả năng liên quan đến việc theo dõi các lastmodified và tên tập tin. Điều này không có nghĩa là bạn cần thăm dò ý kiến ​​khi tìm kiếm thay đổi, thay vào đó, bạn có thể sử dụng FileSystemWatcher làm phương tiện để kích hoạt kiểm tra.

Vì vậy, nếu bạn tiếp tục theo dõi những 50-100 lần cuối cùng ReadDirectoryChangesW /FSW sự kiện đã xảy ra, và bạn thấy rằng nó đang được gọi là nhanh chóng, bạn có thể phát hiện này và kích hoạt các điều kiện đặc biệt để có được tất cả các file đã được thay đổi (và đặt cờ để ngăn tạm thời các sự kiện FSW không có thật trong tương lai) trong vài giây.

Vì một số người nhầm lẫn trong các nhận xét về giải pháp này, tôi đề nghị bạn nên theo dõi các sự kiện diễn ra nhanh như thế nào từ ReadDirectoryChangesW và khi chúng đến quá nhanh, hãy cố gắng giải quyết (thường là quét thủ công một thư mục).

Answer 2

Tôi đã gặp phải sự cố tương tự. Nhưng, tôi không tìm thấy một giải pháp đảm bảo để có được tất cả các sự kiện. Trong một số thử nghiệm, tôi có thể biết rằng chức năng ReadDirectoryChangesW nên được gọi lại càng nhanh càng tốt sau khi chức năng GetQueuedCompletionStatus được trả về. Tôi đoán nếu tốc độ xử lý của hệ thống tập tin là rất nhanh hơn tốc độ xử lý ứng dụng của tôi, ứng dụng có thể mất một số sự kiện.

Dù sao, tôi đã tách một logic phân tích cú pháp khỏi logic theo dõi và đặt logic phân tích cú pháp trên một chuỗi.

Answer 3

Chúng tôi chưa bao giờ thấy ReadDirectoryChangesW đáng tin cậy 100%. Nhưng, cách tốt nhất để xử lý nó là tách biệt "báo cáo" khỏi "xử lý".

Triển khai của tôi có một chuỗi chỉ có một công việc, để xếp lại tất cả các sự kiện. Sau đó, một chủ đề thứ hai để xử lý hàng đợi trung gian của tôi. Về cơ bản, bạn muốn cản trở việc báo cáo các sự kiện càng ít càng tốt.

Trong các tình huống CPU cao, bạn cũng có thể cản trở việc báo cáo sự kiện của người xem.