Hazel Contents Contain не работает: причина и как это исправить

Если условие Contents Contain в Hazel не находит файлы, для начала посмотрите, что оно на самом деле читает: не сам файл, а индекс Spotlight. Пока Spotlight не проиндексировал файл — он новый, синхронизирован из облака, лежит на внешнем диске или папка исключена из поиска, — условие не найдёт ничего, даже если нужный текст лежит прямо внутри документа. Форум поддержки Noodlesoft прямо называет решение: переключить правило на Contents Contain Match, которое читает сам файл и полностью обходит Spotlight. Это медленнее. Noodlesoft говорит об этом открыто. Медленнее и правильно — лучше, чем быстро и неверно.

Это решение снимает проблему меньше чем за минуту в большинстве случаев. Дальше в статье — почему это вообще происходит, ещё три проверки на случай, если одного переключения условия не хватило, и честный разговор о том, где сопоставление по содержимому в Hazel по-прежнему сильнее любой альтернативы, включая File Arbor.

Почему Contents Contain в Hazel перестаёт находить файлы?

У Hazel есть два разных условия для проверки содержимого файла, и работают они принципиально по-разному. Contents Contain спрашивает у Spotlight, есть ли слово внутри файла, — само содержимое файла при этом никто не открывает. Contents Contain Match открывает файл и ищет текст напрямую.

Само по себе это разумное разделение. Индекс Spotlight быстрый, и в большинстве случаев точный. Проблема — в разрыве между «файл существует» и «Spotlight закончил его индексировать». Файл, попавший в отслеживаемую папку несколько секунд назад, ещё может быть недоступен для поиска. Файл, синхронизированный из iCloud Drive, Dropbox или Яндекс.Диска, может оставаться непроиндексированным несколько минут — особенно в момент загрузки. Файл на внешнем диске, в сетевой папке или в чём угодно, что попадает под исключения Конфиденциальности Spotlight, вообще не появится в поиске Spotlight — а значит, и Contents Contain его не увидит, сколько бы раз правило ни запускалось.

Ничего из этого не баг в вашем правиле. Правило проверяет индекс, а отстаёт именно индекс. Hazel честно запускает правило каждый раз — просто получает от Spotlight «нет» там, где правильный ответ звучал бы «ещё не готово».

Настоящее решение: переключитесь на Contents Contain Match

Откройте правило, найдите условие по содержимому и замените всплывающее меню с Contents Contain на Contents Contain Match. Для большинства это и есть всё решение целиком — именно к нему обращается форум Noodlesoft, когда кто-то сообщает о пропущенном совпадении, которое на поверку оказывается разрывом в индексации.

Contents Contain Match ничего не спрашивает у Spotlight. Он открывает файл, извлекает текст и ищет по нему в момент запуска правила. Здесь нет ни индекса, который может отстать, ни списка исключений, о который можно споткнуться, ни фонового процесса, который надо ждать. Цена — скорость: прямое чтение файла занимает больше времени, чем проверка таблицы соответствий, — но для типичного объёма папки Загрузки или Документы разницу вы вряд ли заметите.

Если у вас десятки правил с Contents Contain, переписывать их с нуля не нужно. Откройте каждое, замените одно всплывающее меню, сохраните. Для большой библиотеки правил это утомительно, но это механическая правка, а не переделка логики.

Три проверки, прежде чем переделывать все правила

Переключение на Contents Contain Match снимает симптом. Если хочется понять, почему Spotlight вообще пропустил файл — или оставить более быстрое условие там, где это безопасно, — вот ещё три проверки, которые закрывают остальные реальные причины.

1. Переиндексируйте конкретную папку. Найдите через Spotlight или окно Finder слово из файла. Если файл не находится, Spotlight действительно ещё его не проиндексировал. Apple описывает точечное решение: добавьте папку в список Конфиденциальности Spotlight, подождите несколько секунд, затем уберите обратно. Удаление из списка Spotlight воспринимает как сигнал переиндексировать именно эту папку с нуля — это быстрее, чем переиндексация всего диска.
2. Проверьте сам список исключений. Откройте Системные настройки → Siri и Spotlight → Конфиденциальность Spotlight (на старых версиях macOS — Системные настройки → Spotlight → Конфиденциальность) и убедитесь, что отслеживаемая папка — и любая родительская папка, внешний диск или сетевой том, на котором она лежит, — там не оказалась. Папка может попасть в этот список случайно, особенно после восстановления из бэкапа или переезда на новый Mac.
3. Убедитесь, что в файле вообще есть текстовый слой. Откройте PDF в Preview и попробуйте выделить курсором строку текста. Если ничего не подсвечивается, искать нечего — документ является сканом или фотографией, и без OCR по нему не сработает ни одно условие Hazel. Это отдельная тема, которую мы разбираем в статье про проверку текстового слоя перед настройкой правила.

Что умеет Hazel 6, чего не умеет File Arbor?

Стоит сказать прямо, потому что это честный ответ: если ваши файлы — в основном зашифрованные PDF, для этой задачи Hazel подходит лучше, и ничто ниже этого не меняет.

Hazel 6 добавила распознавание текста на лету — в документации Noodlesoft это описано как OCR, который запускается «для изображений (и для PDF, у которых ещё нет текстового слоя)» прямо перед попыткой сопоставления. Это значит, что отсканированный счёт или фото чека с телефона — файл, в котором в буквальном смысле нет извлекаемого текста, — всё равно может совпасть с правилом Hazel. Hazel 6 также научилась принимать пароль для зашифрованного PDF, поэтому заблокированный документ не просто молча проваливает проверку.

До версии 1.3.0 File Arbor не умел ни того, ни другого. С тех пор правило Pro, настроенное также читать отсканированные документы, запускает OCR для отсканированных PDF и изображений JPEG, PNG и TIFF, читая первую и последнюю страницу каждого из них. PDF, защищённые паролем, по-прежнему недоступны: опции пароля нет. Это реальный пробел, а не мелкая сноска, и это самая ясная причина, почему пользователю Mac с зашифрованными документами стоит остаться на Hazel, а не переходить на что-то другое.

Contents Contain и Contents Contain Match: коротко

Где здесь есть место для File Arbor — и где его нет

Если вас на самом деле привело сюда желание получить такое же правило по содержимому без мыслей о зависимости от Spotlight, именно тут File Arbor ближе к Contents Contain Match, чем к Contents Contain. Его условие «содержимое содержит» — функция уровня Pro — читает текст файла напрямую: поискового индекса в цепочке нет вообще, ни на одной из двух операционных систем, где он работает. Правило, которое ищет krakow, найдёт и «Kraków» в тексте документа, потому что сравнение игнорирует регистр и диакритические знаки, и работает оно одинаково что на Windows, что на macOS. File Arbor читает PDF с текстовым слоем, DOCX и обычный текст, а с версии 1.3.0 ещё и отсканированные PDF и фотографии, если правило настроено на их чтение, — но действует тот же список ограничений, что и везде, где заходит речь о сопоставлении по содержимому: никаких таблиц, никаких колонтитулов, футеров и сносок DOCX, никаких зашифрованных PDF.

Вот что на самом деле стоит назвать разницей. Условия по содержимому в Hazel работают только в macOS. У File Arbor они кроссплатформенные — одно и то же правило, следящее за папкой, на Windows или Mac, из одного приложения. Для рабочего процесса только на Mac это не повод переходить: Hazel уже делает то, что вам нужно, и делает больше — как только в игру вступают зашифрованные PDF. Это важно, только если у вас есть ещё и Windows-машина с такими же правилами, которые вы хотите синхронизировать вручную.

Стоит быть точным и в другом: условия по содержимому в File Arbor выбирают только папку назначения, и больше ничего. Вытащить текст из документа в новое имя файла — отдельная функция Pro, добавленная в версии 1.3.0: вы один раз нажимаете на значение, например на дату счёта, в образце документа, и правило строит из него имя файла и папки. Hazel это умеет тоже, захватывая совпавший фрагмент в отдельный токен. Более широкий разбор того, что умеет и не умеет сопоставление по содержимому в разных инструментах, — в нашем руководстве по сортировке файлов по папкам на основе содержимого.

Какое исправление попробовать первым?

«Правило работало вчера и перестало сегодня, папка та же, файлы те же». Сначала переключите это правило на Contents Contain Match. Почти всегда это разрыв в индексации, и вариант Match полностью его обходит.

«Файл лежит на OneDrive, Dropbox или внешнем диске». Прежде всего проверьте Конфиденциальность Spotlight для этого тома. Облачные клиенты и внешние диски чаще всего оказываются исключены из поиска без чьего-либо злого умысла.

«Я сам скопировал текст из PDF, и он там точно есть». Дальше проверьте текстовый слой — тест с выделением текста в Preview занимает десять секунд и сразу говорит, действительно ли дело в отсутствующем OCR.

«У меня сканы или PDF с паролем, и всё вышеперечисленное не про меня». Оставайтесь на Hazel и используйте её OCR и опцию пароля. Исправление в Spotlight сюда не дотянется, а File Arbor Pro, хотя и читает сканы с версии 1.3.0, не умеет открывать PDF, защищённые паролем, — это настоящее преимущество Hazel, и эта статья не станет вас от него отговаривать.

«Хочу такое же правило по содержимому ещё и на Windows-машине». Это единственный случай, когда File Arbor стоит попробовать — не как замену Hazel, а как способ прогнать эквивалентное правило на второй платформе, куда Hazel не добирается.

Как сохранить надёжность правил по содержимому в будущем

Для любой папки, которая синхронизируется с облаком или лежит на съёмном носителе, по умолчанию выбирайте Contents Contain Match — небольшая потеря скорости того стоит, чтобы больше никогда не гадать, догнал ли Spotlight реальность. Оставляйте обычный Contents Contain для папок на основном внутреннем диске, где вы уже убедились, что индексация не отстаёт: там это более быстрый вариант, и индекс действительно актуален.

Проверяйте новое правило по содержимому на файле, про который вы точно знаете, что он должен совпасть, прежде чем доверять его будущим файлам. Правило, которое молча ничего не делает, заметить куда сложнее, чем правило, которое сработало не там, — а условия по содержимому как раз склонны молча проваливаться, когда извлечение текста, будь то через Spotlight или напрямую, ничего не находит.

FAQ

Почему условие Contents Contain в Hazel не находит мои файлы?

Contents Contain ищет по индексу Spotlight, а не по самому файлу. Если Spotlight ещё не проиндексировал файл — он новый, синхронизирован из облака, лежит на внешнем диске или папка исключена в Конфиденциальности Spotlight — условие не найдёт ничего, даже если текст точно есть внутри документа. Форум поддержки Noodlesoft подтверждает: это самая частая причина.

В чём разница между Contents Contain и Contents Contain Match в Hazel?

Contents Contain проверяет индекс Spotlight и работает быстро; Contents Contain Match читает сам файл напрямую и работает медленнее, зато вообще не зависит от Spotlight. Noodlesoft советует переключаться на второй вариант всякий раз, когда первый пропускает файл, который должен был совпасть, — прямое чтение нельзя обмануть устаревшим или неполным индексом.

Как исправить ситуацию, когда Contents Contain в Hazel не работает?

Откройте правило и замените условие Contents Contain на Contents Contain Match — это официальная рекомендация Noodlesoft, и она работает, потому что вариант Match читает текст файла напрямую, а не полагается на Spotlight. Если это не помогло, проверьте, действительно ли Spotlight проиндексировал папку, и есть ли у файла настоящий текстовый слой, а не просто скан.

Может ли Hazel читать отсканированные PDF или фотографии документов?

Да, начиная с Hazel 6. Noodlesoft добавила распознавание текста на лету — оно запускает OCR для изображений и PDF без текстового слоя прямо перед сопоставлением, — а также опцию указать пароль для зашифрованного PDF. Более ранние версии Hazel и большинство конкурентов на основе правил не могут прочитать файл без текстового слоя вообще; File Arbor Pro может с версии 1.3.0, но опции пароля у него нет.

Есть ли у File Arbor та же зависимость от Spotlight, что и у Hazel?

Нет. Условия по содержимому в File Arbor читают текст файла напрямую — так же, как Contents Contain Match в Hazel, — поэтому там просто нет поискового индекса, который мог бы устареть или из которого можно исключить папку. Компромисс тот же, что Hazel принимает для своего прямого чтения: это медленнее проверки индекса, но никогда не зависит от того, добрался ли Spotlight до файла первым.

Может ли File Arbor заменить Hazel для OCR или зашифрованных PDF?

Для сканов — да, с версии 1.3.0, но File Arbor Pro читает только первую и последнюю страницу; для зашифрованных PDF — нет. File Arbor не может открыть PDF, защищённый паролем, поэтому зашифрованный документ никогда не совпадёт с условием по содержимому в File Arbor. Hazel 6 умеет и то, и другое. Если ваши файлы — в основном зашифрованные PDF, Hazel подходит лучше; преимущество File Arbor — одни и те же правила по содержимому на Windows и Mac без зависимости от Spotlight.

Итог

Условие Contents Contain в Hazel не сломано — оно честно отвечает по тому, что успел проиндексировать Spotlight, а это не всегда совпадает с тем, что реально есть в файле. Переключите правило на Contents Contain Match, и разрыв со Spotlight исчезает целиком. Если в вашей работе есть зашифрованные PDF, поддержка паролей в Hazel 6 делает то, чего сейчас не сделает ни исправление в Spotlight, ни правило File Arbor.

Если у вас есть файлы и на Windows, и хочется такое же правило по содержимому там, бесплатного тарифа File Arbor достаточно, чтобы проверить правило на своих файлах, прежде чем решать, стоит ли добавлять его рядом с Hazel — не вместо неё. На странице цен — что именно входит в условия по содержимому уровня Pro.