FileSystemWatcher vs опитування, щоб спостерігати за змінами файлів

Мені потрібно налаштувати додаток, який спостерігає за файлами, що створюються в каталозі, локально або на мережевому диску.

Буде FileSystemWatcherнайкращим варіантом чи опитування за таймером. Я використовував обидва методи в минулому, але не широко.

Які проблеми (продуктивність, надійність тощо) виникають у будь-якого методу?

Я бачив, як спостерігач файлової системи вийшов з ладу у виробничих та тестових середовищах. Зараз я вважаю це зручністю, але не вважаю його надійним. Моя модель полягає в тому, щоб спостерігати за змінами за допомогою спостерігача файлової системи, але час від часу запитуйте, щоб знайти застарілі зміни файлів.

Редагувати: Якщо у вас є інтерфейс користувача, ви також можете надати користувачеві можливість "оновити" зміни замість опитування. Я б поєднав це з динаміком файлової системи.

Найбільшою проблемою у мене були відсутні файли, коли буфер заповнюється. Легкий як пиріг для виправлення - просто збільште буфер. Пам’ятайте, що він містить назви файлів та події, тому збільште його до очікуваної кількості файлів (проб і помилок). Він використовує пам'ять, яку неможливо випустити на екран, тому вона може змусити інші процеси створювати сторінку, якщо пам'ять втрачається.

Ось стаття MSDN про буфер: FileSystemWatcher .. ::. Властивість InternalBufferSize

На MSDN:

Збільшення розміру буфера коштує дорого, оскільки воно виходить із пам'яті, що не піддається тимчасовому підключенню, яку неможливо замінити на диск, тому зберігайте буфер якомога менше. Щоб уникнути переповнення буфера, використовуйте властивості NotifyFilter та IncludeSubdirectories, щоб відфільтрувати сповіщення про небажані зміни.

Ми використовуємо 16 Мб завдяки великій партії, яка очікується за один раз. Добре працює і ніколи не пропускає файл.

Ми також читаємо всі файли, перш ніж почати обробляти навіть один ... дістаємо імена файлів, які безпечно кешуються (у нашому випадку - в таблицю бази даних), а потім обробляємо їх.

Для проблем із блокуванням файлів я породив процес, який очікує розблокування файлу, очікуючи одну секунду, потім дві, потім чотири та ін. Ми ніколи не опитуємось. Це було без помилок на виробництві вже близько двох років.

Також FileSystemWatcherможна пропустити зміни під час зайнятості, якщо кількість змін у черзі переповнює наданий буфер. Це не обмеження самого класу .NET, а базової інфраструктури Win32. З нашого досвіду, найкращий спосіб мінімізувати цю проблему - це якнайшвидше скасувати сповіщення та вирішити їх з іншого потоку.

Як згадував @ChillTemp вище, спостерігач може не працювати на акціях, що не належать до Windows. Наприклад, він зовсім не працюватиме на встановлених накопичувачах Novell.

Я погоджуюся, що хороший компроміс - це робити епізодичне опитування, щоб зібрати будь-які пропущені зміни.

Також зауважте, що спостерігач файлової системи не є надійним для загальних файлів. Особливо, якщо спільний доступ до файлів розміщений на сервері, який не є Windows. ЖКС не слід використовувати для нічого критичного. Або слід використовувати з епізодичним опитуванням, щоб переконатися, що він нічого не пропустив.

Особисто я користувався FileSystemWatcherвиробничою системою, і вона спрацювала чудово. За останні 6 місяців у нього не було жодної гикавки 24x7. Це моніторинг однієї локальної папки (яка є спільною). У нас відносно невелика кількість файлових операцій, з якими вона має оброблятись (10 подій, знятих на день). Це не те, про що мені колись доводилося хвилюватися. Я б знову скористався, якби переробити рішення.

Зараз я використовую FileSystemWatcherXML-файл, що оновлюється в середньому кожні 100 мілісекунд.

Я виявив, що доки FileSystemWatcherправильно налаштовано, ви ніколи не повинні мати проблем з локальними файлами.

Я не маю досвіду перегляду віддалених файлів та спільних для Windows.

Я вважаю, що опитування файлу буде зайвим і не вартує накладних витрат, якщо ви за своєю суттю не довіряєте FileSystemWatcherабо безпосередньо не відчували обмежень, які всі інші перераховували тут (не для спільних акцій Windows, а також для віддаленого перегляду файлів).

Я б пішов на опитування.

Проблеми з мережею викликають FileSystemWatcherненадійність (навіть при перевантаженні події помилки).

У мене виникли проблеми з використанням FileSystemWatcherмережевих акцій. Якщо ви перебуваєте в чистому середовищі Windows, це може не бути проблемою, але я спостерігав за подією NFS, і оскільки NFS є без громадянства, жодного разу не було повідомлень про зміну файлу, який я переглядав.

У мене виникли великі проблеми з FSW на мережевих накопичувачах: Видалення файлу завжди кидало подію помилки, ніколи не видаляла подію. Я не знайшов рішення, тому зараз уникаю ЖКС і використовую опитування.

Події створення, з іншого боку, спрацювали чудово, тому якщо вам потрібно лише стежити за створенням файлів, ви можете перейти до FSW.

Крім того, у мене зовсім не було проблем із локальними папками, незалежно від того, поділялися вони чи ні.

Повернувшись із методу події якнайшвидше, використовуючи інший потік, вирішили для мене проблему:

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

На мою думку, використання ЖКС та опитування - це марна трата часу та ресурсів, і я здивований, що досвідчені розробники пропонують це. Якщо вам потрібно скористатися опитуванням, щоб перевірити наявність будь-яких пропусків ЖКС, то, природно, ви можете взагалі відмовитись від ЖКС і використовувати лише опитування.

Наразі я намагаюся вирішити, чи буду використовувати ЖКС чи опитування для проекту, який розробляю. Читаючи відповіді, очевидно, що є випадки, коли ЖКС повністю задовольняє потреби, в той час як в інших випадках потрібно опитування. На жаль, жодна відповідь насправді не стосувалася різниці в продуктивності (якщо вона є), лише з питаннями "надійності". Хтось може відповісти на цю частину питання?

EDIT: Точка nmclean щодо обґрунтованості використання як ЖКС, так і опитування (ви можете прочитати обговорення в коментарях, якщо вас цікавить) представляється дуже раціональним поясненням, чому можуть виникнути ситуації, коли використання ЖКС та опитування є ефективний. Дякую, що ви пролили світло на мене (і хтось інший, хто має таку ж думку), nmclean .

Робоче рішення для роботи зі створенням події замість зміни

Навіть для копіювання, вирізання, вставки, переміщення.

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

Рішення для цього спостерігача файлів під час події зміни атрибутів файлів за допомогою статичного зберігання

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

Це вирішення вирішення цієї проблеми з декількома подіями, що викликають події.

Я б сказав, використовуйте опитування, особливо в сценарії TDD, оскільки набагато простіше знущатись / стримувати наявність файлів або іншим чином, коли викликається подія опитування, ніж покладатися на більш "неконтрольовану" подію fsw. + до того, працюючи над низкою програм, які зазнали помилок fsw.