Нашел еще один глюк: Когда в синхронизируемый каталог переносится каталог с вложенными каталогами/файлами, то pyinotify хотя и начинает вотчить все вложенные каталоги, но вот событий на помещение всего содержимого перенесенного каталога не формирует (ну собственно же там ничего и не создается и не переносится).
Глюк только при переносе, при копировании - все отлавливается по событиям на ура (причем большие файлы еще и кучу событий об обновлении пришлют).
Первой мыслью было взвести некий флаг когда перенесен непустой каталог и по флагу запускать полную синхронизацию.....
Но потом подумалось, что это не разумно - ведь полная синхронизация довольно сложный процесс, который учитывает кучу вещей, а тут то нужно учесть только каталоги исключения, а все остальное нужно тупо лить на диск, причем т.к. лью стазу пачку, то могу сначала создать сам перенесенный и все вложенные каталоги, а уже потом закидать в очередь на исполнение задачи на upload файлов в эту структуру - так можно почти со 100% вероятностью сделать все быстро и без ошибок.
Но задача рекурсивной заливки при все свой простоте довольно продолжительная (последовательное создание каталогов для избежания ситуации с гонками "кто быстрее создастся") поэтому я оформил ее как задачу, которую можно отдать PoolExecutor-у.
Собственно и процедуру полной синхронизацию я тоже переделал на выполнение через PoolExecutor, а то изначально у меня эта процедура на старте исполнялась основным потоком, а в работе потоком, основная роль, которого - отслеживание изменений статуса клиента и реакции на эти изменения.
Теперь у меня все продолжительные задачи (простые операции с облаком, полная синхронизация и рекурсивная заливка в облако) выполняются через PoolExecutor, что с одной стороны позволяет более оперативно и правильно работать потоку который занимается статусами и реакциями, и с другой стороны полная синхронизация и массовая заливка точно также отрабатываются по статусу как переход в busy на время исполнения, и возврат в idle после окончания синхронизации/заливки и всех порожденных ими задач. Это позволило убрать скачки статуса из busy в idle и обратно... да и такое изменения статуса более адекватно действительности (ведь клиент активно работает не только когда непосредственно к облаку обращается).