Contents Contain w Hazel nie działa: napraw to krok po kroku

Jeśli warunek Contents contain w Hazel nie znajduje pliku, sprawdź najpierw, co on właściwie odczytuje: nie sam plik, tylko indeks Spotlight tego pliku. Gdy Spotlight nie zdążył zaindeksować pliku - jest nowy, zsynchronizowany z chmury, albo folder jest wykluczony z wyszukiwania - warunek nic nie znajduje, mimo że tekst leży w środku dokumentu. Forum wsparcia Noodlesoft podaje rozwiązanie wprost: przełącz regułę na Contents contain match, który czyta plik bezpośrednio i pomija Spotlight całkowicie. Jest wolniejszy. Noodlesoft mówi to otwarcie. Wolniej, ale poprawnie - to lepsze niż szybko i błędnie.

Ta poprawka rozwiązuje większość przypadków w mniej niż minutę. Reszta artykułu tłumaczy, dlaczego problem się pojawia, trzy dodatkowe rzeczy do sprawdzenia, jeśli sama zmiana warunku nie wystarczy, i miejsca, w których dopasowywanie treści w Hazel wciąż bije każdą alternatywę, File Arbor włącznie.

Dlaczego "Contents contain" przestaje działać?

Hazel ma dwa osobne warunki sprawdzające, co jest w środku pliku, i działają one w zupełnie inny sposób. Contents contain pyta Spotlight, czy słowo pojawia się w pliku - nigdy nie otwiera samego pliku. Contents contain match otwiera plik i przeszukuje tekst bezpośrednio.

To rozsądny projekt. Indeks Spotlight jest szybki i przez większość czasu trafny. Problem leży w przerwie między "plik istnieje" a "Spotlight skończył indeksować plik". Plik dodany do monitorowanego folderu kilka sekund temu może jeszcze nie być przeszukiwalny. Plik zsynchronizowany z iCloud Drive, Dropboksa albo OneDrive'a potrafi leżeć niezaindeksowany przez minuty, zwłaszcza w trakcie pobierania albo na kliencie synchronizacji w wersji beta. Plik na zewnętrznym dysku, udziale sieciowym albo w folderze objętym wykluczeniami Spotlight Privacy w ogóle nie pojawi się w wynikach wyszukiwania Spotlight - co oznacza, że Contents contain też go nie zobaczy, niezależnie od tego, ile razy reguła się uruchomi.

Żadna z tych sytuacji nie jest błędem w twojej regule. Reguła sprawdza indeks, a to indeks jest tym, co zostaje w tyle. Hazel uruchamia regułę poprawnie za każdym razem - po prostu dostaje od Spotlight odpowiedź "nie", gdy uczciwa odpowiedź brzmi "jeszcze nie".

Prawdziwa naprawa: przełącz na "Contents contain match"

Otwórz regułę, znajdź warunek treści i zmień rozwijane menu z Contents contain na Contents contain match. Dla większości osób to cała poprawka, i to właśnie po nią sięga forum Noodlesoft, gdy ktoś zgłasza brak dopasowania, który okazuje się luką w indeksowaniu.

Contents contain match niczego nie pyta Spotlight. Otwiera plik, wyodrębnia tekst i przeszukuje go w momencie uruchomienia reguły. Nie ma indeksu, który mógłby zostać w tyle, nie ma listy wykluczeń, o którą można się potknąć, nie ma czekania, aż proces w tle nadrobi zaległości. Kosztem jest szybkość - bezpośredni odczyt pliku trwa dłużej niż sprawdzenie tabeli - ale przy typowej objętości folderu Pobrane czy Dokumenty ta różnica jest niezauważalna.

Jeśli utrzymujesz dziesiątki reguł opartych na Contents contain, nie musisz budować ich od nowa. Otwórz każdą, zmień jedno rozwijane menu i zapisz. Przy dużej bibliotece reguł to żmudne, ale to mechaniczna edycja, nie przeprojektowanie.

Trzy dodatkowe rzeczy do sprawdzenia, zanim przebudujesz wszystkie reguły

Przełączenie na Contents contain match naprawia objaw. Jeśli chcesz wiedzieć, dlaczego Spotlight w ogóle pominął plik - albo wolisz zostawić szybszy warunek tam, gdzie to bezpieczne - te trzy sprawdziany pokrywają resztę realnych przyczyn.

1. Zreindeksuj konkretny folder. Poszukaj słowa z pliku w Spotlight albo oknie Findera. Jeśli plik się nie pojawia, Spotlight naprawdę jeszcze go nie zaindeksował. Apple opisuje celowaną poprawkę: dodaj folder do listy Spotlight Privacy, odczekaj kilka sekund, a potem usuń go z tej listy. Spotlight traktuje to usunięcie jako sygnał do reindeksacji tego folderu od zera, co jest szybsze niż reindeksacja całego dysku.
2. Sprawdź samą listę wykluczeń Privacy. Otwórz Ustawienia systemowe → Spotlight → Search Privacy (Preferencje systemowe → Spotlight → Privacy na starszych wersjach macOS) i potwierdź, że monitorowany folder - oraz każdy folder nadrzędny, zewnętrzny dysk czy wolumin sieciowy, na którym leży - nie jest już wykluczony. Folder może się tam znaleźć przez przypadek, zwłaszcza po przywróceniu z kopii zapasowej albo migracji na nowego Maca.
3. Potwierdź, że plik w ogóle ma warstwę tekstową. Otwórz PDF w Podglądzie i spróbuj zaznaczyć kursorem linijkę tekstu. Jeśli nic się nie podświetla, nie ma czego przeszukiwać - dokument to zeskanowany obraz albo zdjęcie, i żaden warunek Hazel go nie dopasuje bez OCR, co omawiamy dalej.

Co potrafi Hazel 6, czego nie potrafi File Arbor?

Warto powiedzieć to wprost, bo to uczciwa odpowiedź: jeśli twoje pliki to głównie zaszyfrowane PDF-y, Hazel jest do tego zadania lepszym narzędziem, i nic poniżej tego nie zmienia.

Hazel 6 dodał rozpoznawanie tekstu w locie - własna dokumentacja Noodlesoft opisuje to jako OCR uruchamiany "na obrazach (oraz na PDF-ach, które nie mają jeszcze warstwy tekstowej)", zanim reguła spróbuje je dopasować. Oznacza to, że zeskanowana faktura albo zdjęcie paragonu zrobione telefonem - coś bez żadnego tekstu do wyodrębnienia - wciąż może dopasować regułę Hazel. Hazel 6 dodał też możliwość podania hasła do zaszyfrowanego PDF-a, więc zablokowany dokument nie kończy się po prostu cichym niepowodzeniem.

Przed wersją 1.3.0 File Arbor nie robił żadnej z tych dwóch rzeczy. Od tamtej pory reguła Pro ustawiona tak, by czytała też zeskanowane dokumenty, uruchamia OCR na zeskanowanych PDF-ach oraz na obrazach JPEG, PNG i TIFF, czytając pierwszą i ostatnią stronę każdego z nich. Zabezpieczone hasłem PDF-y wciąż są poza zasięgiem - nie ma opcji podania hasła - i to realna luka, nie drobny dopisek. To jedyny, ale najwyraźniejszy powód, dla którego użytkownik Maca z zaszyfrowanymi dokumentami powinien zostać przy Hazel zamiast się przełączać.

"Contents contain" kontra "Contents contain match" w skrócie

Gdzie pasuje File Arbor - i gdzie zdecydowanie nie

Jeśli to, co faktycznie sprowadziło cię tutaj, to chęć posiadania podobnej reguły treści bez zależności od Spotlight do przemyślenia, to właśnie to miejsce, w którym File Arbor leży bliżej Contents contain match niż Contents contain. Jego warunek "treść zawiera" - funkcja poziomu Pro - czyta tekst pliku bezpośrednio, bez żadnego indeksu wyszukiwania w pętli, na obu systemach, na których działa. Reguła szukająca zamowienie dopasuje też plik zawierający zamówienie, bo porównanie ignoruje wielkość liter i znaki diakrytyczne, i działa dokładnie tak samo na Windows, jak na macOS. Odczytuje PDF-y z warstwą tekstową, pliki DOCX i zwykły tekst, a od wersji 1.3.0 także zeskanowane PDF-y i zdjęcia, gdy reguła jest ustawiona tak, by je czytać, ale obowiązuje ta sama lista luk, co wszędzie indziej przy dopasowywaniu treści: brak arkuszy kalkulacyjnych, brak nagłówków, stopek i przypisów DOCX-a, brak zaszyfrowanych PDF-ów.

To ostatnie jest tą realną różnicą, którą warto nazwać wprost. Warunki treści w Hazel działają wyłącznie na macOS. Warunki File Arbor są wieloplatformowe - ta sama reguła, monitorująca folder, na Windows albo Macu, z jednej aplikacji. Przy workflow tylko na Macu to nie jest powód do zmiany - Hazel już robi to, czego potrzebujesz, i robi więcej, gdy w grę wchodzą zaszyfrowane PDF-y. Ma to znaczenie tylko wtedy, gdy utrzymujesz też reguły na komputerze z Windows i chcesz, żeby się zgadzały.

Warto też być precyzyjnym co do tego, co robią warunki treści File Arbor: wybierają wyłącznie folder docelowy, nic więcej. Wyciągnięcie tekstu z dokumentu do nowej nazwy pliku to osobna funkcja Pro, dodana w wersji 1.3.0: klikasz raz wartość, taką jak data faktury, na przykładowym dokumencie, a reguła buduje z niej nazwę pliku i foldery. Hazel to potrafi też, za pomocą przechwyconego dopasowania jako tokenu. Szerszy przegląd tego, co dopasowywanie po treści potrafi i czego nie potrafi w różnych narzędziach, znajdziesz w naszym przewodniku o sortowaniu plików do folderów na podstawie treści.

Który fix wypróbować najpierw?

"Moja reguła pasowała wczoraj, dziś przestała, ten sam folder, te same pliki." Najpierw przełącz tę regułę na Contents contain match. To niemal zawsze luka w indeksowaniu, a wariant match ją całkowicie omija.

"Plik jest na OneDrive, Dropboksie albo zewnętrznym dysku." Sprawdź Spotlight Privacy dla tego woluminu, zanim zrobisz cokolwiek innego. Klienty synchronizacji chmurowej i zewnętrzne dyski to najczęstsze miejsca, w których folder ląduje na liście wykluczeń bez niczyjego celowego działania.

"Sam wkleiłem tekst z tego PDF-a, na pewno tam jest." Wyklucz brak warstwy tekstowej jako kolejny krok - test zaznaczania tekstu w Podglądzie zajmuje dziesięć sekund i od razu mówi, czy brakującym elementem jest OCR.

"Mam zeskanowane dokumenty albo zaszyfrowane PDF-y i nic z powyższego się nie stosuje." Zostań przy Hazel i korzystaj z jego opcji OCR i hasła. Poprawka związana ze Spotlight tam cię nie zaprowadzi, a File Arbor Pro czyta wprawdzie skany od wersji 1.3.0, ale nie otworzy PDF-ów zabezpieczonych hasłem - to realna przewaga Hazel, i ten artykuł cię z niej nie wyprowadzi.

"Chcę tej samej reguły treści też na komputerze z Windows." To jedyny przypadek, w którym warto rozejrzeć się za File Arbor - nie jako zamiennik Hazel, tylko sposób na uruchomienie równoważnej reguły na drugiej platformie, do której Hazel nie dociera.

Jak utrzymać reguły treści niezawodne na przyszłość

Domyślnie ustawiaj Contents contain match dla każdej reguły monitorującej folder, który synchronizuje się z chmurą albo leży na nośniku wymiennym - niewielki koszt szybkości wart jest tego, żeby nigdy nie zastanawiać się, czy Spotlight nadążył. Zostaw zwykły Contents contain dla folderów na głównym dysku wewnętrznym, gdzie potwierdziłeś, że indeksowanie nadąża, bo to szybsza opcja, gdy indeks jest faktycznie aktualny.

Przetestuj nową regułę treści na pliku, o którym już wiesz, że pasuje, zanim zaufasz jej przy nowych plikach. Regułę, która po cichu nic nie robi, dużo trudniej zauważyć niż regułę, która uruchamia się, gdy nie powinna, a warunki treści to dokładnie ten rodzaj reguły, który zawodzi po cichu, gdy leżące u podstaw wyodrębnianie tekstu - przez Spotlight albo bezpośredni odczyt - nie znajduje niczego.

FAQ

Dlaczego warunek Contents contain w Hazel nie dopasowuje moich plików?

Contents contain przeszukuje indeks Spotlight, nie sam plik. Jeśli Spotlight nie zdążył zaindeksować pliku - bo jest nowy, zsynchronizowany z chmury, na zewnętrznym dysku albo folder jest na liście wykluczeń Spotlight Privacy - warunek nic nie znajduje, mimo że tekst wyraźnie jest w środku dokumentu. Sam producent, Noodlesoft, potwierdza na swoim forum, że to najczęstsza przyczyna.

Jaka jest różnica między Contents contain a Contents contain match w Hazel?

Contents contain sprawdza indeks Spotlight i jest szybki; Contents contain match czyta plik bezpośrednio - wolniej, ale bez żadnej zależności od Spotlight. Noodlesoft poleca drugą opcję zawsze, gdy pierwsza nie dopasuje pliku, który powinna, bo bezpośredniego odczytu nie da się oszukać nieaktualnym albo niepełnym indeksem.

Jak naprawić błąd, gdy Contents contain nie działa w Hazel?

Otwórz regułę i zmień warunek z Contents contain na Contents contain match - to oficjalna poprawka polecana przez Noodlesoft, skuteczna, bo wariant match czyta tekst pliku bezpośrednio zamiast polegać na Spotlight. Jeśli to nie pomoże, sprawdź, czy Spotlight faktycznie zaindeksował folder i czy plik ma prawdziwą warstwę tekstową, a nie jest zeskanowanym obrazem.

Czy Hazel potrafi odczytać zeskanowane PDF-y albo zdjęcia dokumentów?

Tak, od Hazel 6. Noodlesoft dodał rozpoznawanie tekstu w locie, które uruchamia OCR na obrazach i na PDF-ach bez istniejącej warstwy tekstowej, zanim spróbuje je dopasować, a także opcję podania hasła do zaszyfrowanego PDF-a. Wcześniejsze wersje Hazel i większość konkurencji opartej na regułach nie odczytają pliku bez żadnej warstwy tekstowej; File Arbor Pro potrafi to od wersji 1.3.0, ale nie ma opcji podania hasła.

Czy File Arbor ma tę samą zależność od Spotlight co Hazel?

Nie. Warunki dopasowywania treści w File Arbor czytają tekst pliku bezpośrednio, tak jak Contents contain match w Hazel, więc nie ma tu indeksu wyszukiwania, który mógłby się zdezaktualizować albo wykluczyć folder. Kompromis jest taki sam, jaki akceptuje sam Hazel przy swoim wariancie bezpośredniego odczytu: czytanie pliku jest wolniejsze niż sprawdzenie indeksu, ale nigdy nie zależy od tego, czy Spotlight zdążył dotrzeć do pliku pierwszy.

Czy File Arbor zastąpi Hazel przy OCR albo zaszyfrowanych PDF-ach?

W przypadku skanów tak, od wersji 1.3.0, choć File Arbor Pro czyta tylko pierwszą i ostatnią stronę; w przypadku zaszyfrowanych PDF-ów nie. Nie otworzy PDF-a zabezpieczonego hasłem, więc zaszyfrowany dokument nigdy nie dopasuje reguły treści w File Arbor. Hazel 6 robi obie te rzeczy. Jeśli twoje pliki to głównie zaszyfrowane PDF-y, lepszym wyborem jest Hazel; przewagą File Arbor jest uruchamianie tych samych reguł treści na Windows i Mac bez zależności od Spotlight.

Podsumowanie

Warunek Contents contain w Hazel nie jest zepsuty - odpowiada uczciwie na podstawie tego, co zaindeksował Spotlight, a to nie zawsze to samo, co faktycznie jest w pliku. Przełącz regułę na Contents contain match, a luka związana ze Spotlight znika całkowicie. Jeśli zaszyfrowane PDF-y są częścią twojego workflow, obsługa haseł w Hazel 6 robi coś, czego dziś nie zrobi żadna poprawka związana ze Spotlight ani żadna reguła File Arbor.

Jeśli trzymasz pliki także na Windows i chcesz mieć tam podobną regułę treści, darmowy plan File Arbor wystarczy, żeby wypróbować regułę na własnych plikach, zanim zdecydujesz, czy warto dodać go obok Hazel, nie zamiast niego. Zobacz cennik, żeby sprawdzić, co obejmują warunki treści w planie Pro.