Чи є щось подібне до ініціації у Windows?


103

У ОС Linux існує іонотифікована підсистема, яка повідомляє заявку про зміни у файловій системі.

Однак я в основному користувач Windows, тому мені було цікаво, чи існує подібний спосіб моніторингу змін файлової системи?


9
Я не думаю, що такі питання поза темою. Питання задає API OS, який сильно відрізняється від будь-якого інструмента / програмного забезпечення-бібліотеки. Можливо, це може бути сформульовано по-різному, як, як отримувати сповіщення у програмі Windows, коли конкретний файл / файли змінені.
балки

1
Голосували за повторне відкриття: питання задає порівнянну альтернативу конкретній API операційної системи і образно читає мені на кшталт "Я з Англії, де я використовую виделку для їжі, в Японії який посуд я використовую аналогічно? " Прийнята відповідь за цією аналогією - «використовувати палички для їжі».
Девід

Відповіді:



42

Якщо ви використовуєте .net , використовуйте FileSystemWatcher. Більше інформації тут: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Якщо ви використовуєте C , використання FindFirstChangeNotification, FindNextChangeNotification, ReadDirectoryChangesW. Більше інформації тут: http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

У OSX відповідним api є fseventsapi.

Всі вони тонко відрізняються один від одного, і всі вони мають сумнівну надійність у крайових випадках. Взагалі, ви не можете залежати від цих apis для повного перегляду всіх змін у 100% часу. Більшість людей, що використовують моніторинг файлової системи, поєднують її з періодичними скануваннями, щоб компенсувати втрачену або неповну інформацію з push api.


6
Ви можете, будь ласка, надати посилання на "сумнівну надійність у крайовій справі для ініціації?"
Pharaun,

18
Якщо споживач aps watcher api повільніше читає події, ніж якийсь інший процес при їх генеруванні, ядро ​​або повинно утримувати модифікації файлової системи в іншому (можливо, більш пріоритетному) процесі, або допускати необмежене зростання буфера. Глибина буфера inotify (як це зафіксовано на сторінці "man") контролюється / proc / sys / fs / inotify / max_queued_events. Крім цього, ви отримуєте повідомлення IN_Q_OVERFLOW - це добре, але ви все ще залишаєтесь у ситуації, коли час від часу вам може знадобитися повторно переглядати.
blucz

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

@blucz Мені було цікаво, як люди з ядрами вирішують ці ситуації. Приємно знати, що вони роблять це, робить ще одним впевненим у розробці та реалізації.
n611x007


11

JNotify або FileMon від Microsoft.


8
JNotify був ідеальним для мене, оскільки мені потрібна сумісність між платформами. Мені навіть вдалося написати єдиний скрипт bash, який працював у cygwin, mac та linux, припускаючи лише те, що JAVA_HOME встановлений правильно. Це було чудовим підмогою для налагодження проблем на машинах замовника, коли вони кажуть "це видалило мій файл!" Я можу насправді подивитися на журнал і спробувати зрозуміти, як / коли це сталося.
cmyers

1
FileMon зараз ProcessMonitor technet.microsoft.com/en-us/sysinternals/bb896645
MECU

10

Трохи пізно, але ...

У Windows є засоби, подібні до подій OSX, за допомогою яких ви можете відстежувати події, не запускаючи додаток. Журнал Windows USN відстежує всі зміни файлів. Джеффрі Ріхтер (автор Advanced Windows) написав приголомшливу статтю з робочими зразками для журналу MSDN. Оновлення : стаття зараз з archive.org, оскільки MSJ більше не в мережі в MS.

Документація MSDN для журналів змін USN.

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


Чи відрізняється спосіб журналу USN, чи покладається на це, щоб уникнути помилкової поведінки FileSystemWatcher| FindFirstChangeNotification PhillipBrandonHolmes було говорити про ?
n611x007

4
Минув час, коли я працював з цим, але він не використовує FileSystemWatcher або FindFirstChangeNotification. Я почав писати спостерігач подій Windows у Go, базуючись на прикладах Джеффі Ріхтера. З моменту тестування, який я зробив, воно є твердим, і нічого не пропускає, схоже на fsevents в OS X. Суть тут: gist.github.com/pkrnjevic/7219861
Пітер Крневич

@PeterKrnjevic Чи можете ви оновити посилання на статтю від Джефрі Ріхтера?
ДУЮ

@SOUser, через MS bitrot, стаття тепер посилається на archive.org.
Петро Крневич

3

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

JNotify для Windows також ненадійний, оскільки ця помилка походить від win32. JNotify використовує win32. Отже, він не відрізняється від FileSystemWatcher ().


думаючи про те, як створити ролі, щоб вирішити цю проблему, пов'язану зі швидкістю / гонкою / переповненням, я задумався, як це зробили ядра. Цікаво. Ця річ трапляється також при роботі з мережею та веденням журналів. Чи має ця проблема назва?
n611x007

Так, це назва "помилка". Помилка (win32) залишається у будь-якій операційній системі, створеній Microsoft на сьогоднішній день. Це робить будь-яку операційну систему Microsoft непридатною для рішення типу перегляду файлів. Ви повинні виконати * nix, щоб виконати це. Іноді я думаю, що вони навмисно залишили цей переповнення буфера з міркувань безпеки.
Філіп Брендон Холмс

ха-ха ... так ... це ім'я - це навмисне згублення кластера, так що файлова система мікрософт не може бути навмисно дивитися. Це помилка, яку вони залишили через проблеми безпеки.
Філіп Брендон Холмс

1

Я трохи пошукав, схоже, пригадую, побачив щось подібне для Windows. Існує FileSystemWatcher для .NET. Це в основному для NT або XP і вперед.


Він, як правило, доступний лише для файлових систем NTFS, але не для FAT16, FAT32 або навіть нового exFAT.
Мастачеата

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.