Мониторить что бы каждый день в папке создавались файлы
Установка
Можно взять готовую версию из PIP:
$ pip install watchdog
Сам PIP ставится как пакет python-pip, порт devel/py-pip, etc.
Либо собрать из исходников через setup.py.
Достаточно подробно все расписано в оригинальном руководстве. Правда там описание версии 0.5.4, а сейчас актуальна 0.6.0. Однако, вся разница в правке копирайтов и замене отступа в 4 пробела на отступ в 2. «Google code style» :)
Вообще, там довольно много особенностей сборки по версиям самого python так и по целевой платформе. Они все описаны по ссылке выше, но если будет нужно, допишу в статью вкратце на русском.
Кроме того, собрать модуль можно на несовместимой ОС, но тогда в дело вступится fallback-реализация, делающая «слепки» структуры ФС с последующими сравнениями. Возможно, так кто-то и делал у себя при решении подобной задачи :)
Сам же я пробовал собрать под ubuntu 11.4 и freebsd-8.2 RELEASE, каких-либо проблем при сборке и работе не возникло.
Базовый пример
Предположим, что нас интересуют изменения по некоему пути /path/to/smth, связанные с созданием, удалением и переименованием файлов и директорий.
Класс Observer выбирается в /observers/__init__.py исходя из возможностей вашей ОС, так что нет необходимости самостоятельно решать, что же выбрать.
Класс FileSystemEventHandler является базовым классом обработчика событий изменения. Он мало что умеет, но мы научим его потомка:
Полный список методов можно увидеть в самом FileSystemEventHandler.dispatch: on_modified, on_moved, on_created, on_deleted.
Запускаем это все:
Observer является относительно далеким потомком threading.Thread, соотвественно после вызова start() мы получаем фоновый поток, следящий за изменениями. Так что если скрипт сразу завершится, то ничего толкового мы не получим. Реалиация ожидания зависит в первую очередь от применения модуля в реальном проекте, сейчас же можно просто сделать костыль:
Ждем событий изменений ФС до прихода Ctrl+C (SIGINT), после чего говорим нашему потоку завершиться и ждем, пока он это выполнит.
Запускаем скрипт, идем по нашему пути и:
На выходе скрипта имеем:
В методы нашего класса Handler в поле event приходят потомки FileSystemEvent, перечисленные в watchdog/events.py.
У всех есть свойства src_path, is_directory, event_type («created», «deleted», и т.п.). Для события moved добавляется свойство dest_path.
Ну если вы больше ничего не хотите… А разве ещё что-нибудь есть?
- * любые символы
- ? любой единичный символ
- [seq] любой единичный символ из указанных
- [!seq] любой единичный символ НЕ из указанных
RegexMatchingEventHandler делает тоже самое, но с явным указанием regexp-выражений в конструкторе:
PatternMatchingEventHandler внутри себя в итоге транслирует шаблоны в регулярки, так что должен работать медленнее из-за наличия такого оверхеда.
Наконец, LoggingEventHandler выводит все в лог через logging.info().
— Вот и все. Может кому пригодится.
P.S.
При слежении за директорией, в которой (и в ее дочерних) содержатся папки/файлы не с ascii именованием, возникнет исключение exceptions.UnicodeEncodeError в глубинах watchdog'а. В Linux (inotify) он возникает в watchdog.observers.inotify.Inotify._add_watch.
Причина — чтение содержимого в ascii кодировке.
Для исправления ситуации можно пропатчить метод:
Вот пример исходной строки, и ее repr() до и после обработки encode():
Всем привет! Перерыл интернет в поисках оптимального решения и нашел вот такой полезный макрос,
который мониторит папку на наличие файлов с определенным интервалом.
Данный пример работает с одним каталогом, как переделать данный скрипт, чтобы можно было мониторить
все подкаталоги каталога(ну или несколько каталогов одновременно).
Сканирование портов vbs (WMI NetDiagnostics)
В Windows XP все работает, а в Windows 7 нет. Ниже часть кода: Dim wmiQuery wmiQuery = "Select.
VBS Отправка e-mail через SMTP-сервер - VBScript/JScript/WSH/WMI/HTA
Помогите, при запуске скрипта возникает ошибка Option Explicit 'Содание объекта CDO Dim.
Удаление программы средствами WMI
День добрый подскажите смогу ли я через WMI удалить программу установленную не через msi пакет и.
Как узнать средствами WSH или WMI, какие файлы открыты
Как средствами WSH или WMI узнать, открыт файл или нет?
T4gr0id, Это костыль.
Я бы на вашем месте посмотрел в сторону FileSystemWatcher. Описание на MSDN
На powershell реализация совсем плевая.
Используйте FileSystemWatcher для отслеживания изменений в заданном каталоге. Можно отслеживать изменения в файлах и вложенных каталогах заданного каталога. Можно создать компонент, который будет следить за файлами на локальном компьютере, на сетевых дисках или на удаленном компьютере.
Вот простейшая реализация.
Все, что попадает\создается в директорию "D:\DBFS" копируется в директорию "D:\Dump"
Это один из вариантов использования механизма подписки на событие . В найденном вами примере используется асинхронный режим. На этом форуме можно найти примеры использования синхронного режима. Скажем, в этой теме (применительно к задаче наблюдения за каталогом):
VBS Открытие файла в WordPad - VBScript/JScript.
Сам по себе механизм подписки на событие не поддерживает рекурсивного просмотра, поэтому для наблюдения за группой каталогов связка VBS + WMI малоэффективна, хотя при определённых ограничениях вполне реализуема.
Если требуется именно постоянное наблюдение за большой группой каталогов или за их "деревом" произвольного состава и глубины вложенности, то вам вполне справедливо указали в сторону PowerShell.
Однако фраза
вызывает вопрос: а нужен ли здесь вообще механизм подписки? Может достаточно периодической проверки на наличие в папке (группе папок) каких-либо файлов по количественному признаку (при необходимости можно задать шаблон имени и/или расширения)?
Привет всем!
У меня встала задача написать программу для мониторинга файлов и отправки найденных файлов на электронную почту.
Суть в чем. Каждый день в определенной папке(скажем D:\test_folder)создается папка с текущей датой (формата yymmdd). С этим я справился. вот код:
в этой папке с текущем днем создается еще одна папка(имя папки - post), в которую и сыпятся со стороннего приложения файлы, которые и необходимо отправлять на почту.
как отправлять на почту тоже разобрался:
Но отправлять нужно не все файлы которые появляются в данной папке post, а все кроме определенных, то есть надо создать как я понимаю какой-то шаблон файлов, которых не нужно отправлять.(например, это файлы содержащие в своих именах: klas, lic,ort) - эти файлы отправлять не нужно, а остальное все отправляется на почту.
помогите мне пожалуйста допилить код под мою поставленную задачу. надеюсь, что объяснил понятно. заранее очень благодарен и большое спасибо за вашу помощь.
Отправка содержания файлов папки на email. Местоположение папки неизвестно
Всем привет, столкнулся с такой задачей, есть одна папка(ЕОП), с какими-то файлами в ней.
Мониторинг папки на создание новых папок/файлов
Доброго времени суток! Хочу попытаться написать мониторинг для определенной папки на появление.
Отправка на почту несколько файлов
Привет, как мне добавить файлы в разные textbox'ы вот код на кнопку добавить ( вывод в textbox ).
Мониторинг папки на содержание файлов
Всем привет Подскажите, есть задача Мониторинг папки раз в секунду, если в папке появляются.
ну как я понимаю, тебе просто надо просматривать каждый файл, который подвергся изменению, брать его имя и проверять, есть ли в его составе какие-либо сочетания, к примеру так
Orlangur1991, дело в том, что имена не фиксированные, а содержат в себе klas, lic, ort
например имя файла:
05klas123d
54_lic13
Orlangur1991, как я понимаю, что это все необходимо делать в потоке.
Получается так:
Стоит папка на мониторинге(D:\test_folder), в ней папка(D:\test_folder\20161209), в которой еще одна подпапка (D:\test_folder\20161209\files), в которой уже лежат файлы, которые нужно отправлять на почту отправлять на почту.
пока не очень понимаю как связать два кода моих(на мониторинг и отправку файлов).
Можно более подробно (желательно кодом) объяснить. с потоками первый раз в жизни пытаюсь что то сделать. спасибо!
Я бы хотел посвятить статью обзору API, предоставляемых разными ОС для слежения за изменениями в директории. Статья появилась как результат моей работы над демонами слежения за изменениями для утилиты dklab_realsync (статья на хабре, github репозиторий) и своей собственной, которую я пока что не хочу анонсировать.
Для операционной системы Windows есть замечательная функция ReadDirectoryChangesW, которая возвращает набор изменений для директории, в том числе содержит флаг для работы рекурсивно (bWatchSubtree). Таким образом, реализация слежения за изменениями в директории не представляет особого труда и в том же dklab_realsync реализация занимает 80 строк кода или 3.5 Кб. Интересно, что в Windows эти события поддерживаются даже через SMB!
Тем не менее, существуют определенные подводные камни:
- конечный размер буфера изменений, после которого очередь событий переполнится и эти события будут потеряны
- согласно документации к watchdog package, событие перемещения посылается раньше, чем изменения становятся видны в ФС
- размер буфера ограничен в 64 Кб для сетевой ФС
Вывод: Функция ReadDirectoryChangesW позволяет легко узнавать обо всех событиях в файлах, но, очередь событий может переполниться и тогда нужно будет выполнять полное сканирование ФС. Также, возможна доставка событий до того, как они станут актуальны.
В Mac OS X также есть удобный и простой API для слежения за изменениями в файловой системе под названием FSEvents. С использованием этого API простейшая реализация демона составляет 50 строк кода или 1.8 кб. Очередь не может переполниться (!), но полное сканирование все же может потребоваться, если демон fseventsd «упадет». Стоит отметить, что этот API до версии 10.7 не предоставляет изменения по файлам, он сообщает только директории, в которых что-то изменилось. Поскольку события никуда не деваются и пишутся в лог (FSEvents service stores events in a persistent, per-volume database), детализация с точностью для директории позволяет сэкономить место на диске.
Вывод: FSEvents API для Mac OS X является самым необычным из всех подобных API. Очередь не переполняется и даже имеется возможность получить события из прошлого. Тем не менее, детализация событий дается с точностью до директории (до версии 10.7), что означает меньшую эффективность демона для синхронизации файлов.
В linux vanilla kernel существует один способ слежения за изменениями в директории — это inotify. Для этого API существует хорошая и подробная документация, но нет поддержки рекурсивного слежения за изменениями! Также, у inotify есть ограничение на максимальное количество объектов, за которыми можно следить. Простейшая реализация демона занимает уже 250 строк кода или 8 кб. Статическая сборка с использованием dietlibc занимает примерно 14 кб. Другим неприятным моментом является то, что приложение должно само поддерживать соответствия между watch descriptor (в нашем случае это всегда директория) и именем. Есть функция inotify_add_watch, которой передается путь до отслеживаемой директории, но нет обратной — inotify_get_path, которая бы возвращала этот самый путь по переданному дескриптору. События же содержат только watch descriptor и относительный путь до изменившегося файла внутри директории.
Подводные камни рекурсивного слежения за директорией через inotify:
- Возможность переполнения очереди (длина очереди задается в /proc/sys/fs/inotify/max_queued_events)
- Ограничение на максимальное количество объектов слежения (задается в /proc/sys/fs/inotify/max_user_watches)
- Отсутствие возможности рекурсивного слежения за директорией
- Необходимость отдельно обрабатывать случай, когда создается директория (например mkdir -p a/b/c). Вы получите событие о том, что создана директория «a», но пока вы навешиваете обработчик на эту директорию, в ней уже могут создать ещё одну директорию и событие об этом вам уже не придет.
- Теоретическая возможность целочисленного переполнения watch descriptor (wd), так как он задается uint32
FreeBSD и Mac OS X позволяют отслеживать за изменениями с помощью kqueue, который аналогичен inotify по своим характеристикам и также не имеет возможности рекурсивного слежения за директориями. Также, kqueue принимает в качестве аргументов дескрипторы открытых файлов (директорий), поэтому при использовании этого API ограничения на количество отслеживаемых директорий ещё более строгие.
П ри работе за компьютером у вас может возникнуть необходимость постоянно отслеживать изменения в какой-то папке. Делать это вручную с помощью Проводника очень утомительно, будет гораздо лучше, если вы воспользуетесь программкой FolderMonitor. Как понятно из её названия, предназначается она для мониторинга изменений в папках как на локальных, так и на сетевых дисках.
Первым делом, что нужно сделать после запуска исполняемого файла утилиты, это воспользовавшись опцией меню «Add folder», составить список отслеживаемых ресурсов.
Это может быть любой каталог, диск либо раздел, доступный через традиционное окошко обзора. После этого FolderMonitor начнёт мониторить их содержимое.
Большую часть времени утилита проводит в системном трее, никак себя не проявляя.
Но если вы или какая-нибудь программа что-то изменит в отслеживаемой папке, утилита тут же даст о себе знать окошком с оповещением о произведённых изменениях.
Отслеживаются любые изменения — создание, удаление, переименование и модификация объектов — файлов, папок, ярлыков и других типов данных. При этом показывается точное время изменения, путь, имя и тип действия.
Появление окошка сопровождается звуковым сигналом, отключить или изменить который можно в настройках утилиты. Программкой поддерживается выбор режима оповещений (окошко и всплывающая панель в трее) , включение и отключение событий, а также выполнение пользовательских команд при их наступлении.
Последняя функция наверняка заинтересует опытных пользователей, с её помощью можно автоматизировать некоторые операции, например, организовать резервное копирование объектов при наступлении определённого события.
Из дополнительных возможностей FolderMonitor стоит также отметить добавление в автозагрузку Windows, использование фильтров (пригодится при настройке исключений) и установку паузы для оповещений, связанных с одним и тем же объектом.
Читайте также: