Hazel Contents Contain funktioniert nicht: Ursache und Lösung

Funktioniert Hazels Contents-Contain-Bedingung nicht, sehen Sie sich zuerst an, was sie tatsächlich liest, bevor Sie irgendwo anders suchen: nicht die Datei, sondern Spotlights Index der Datei. Hat Spotlight etwas noch nicht indiziert – eine neue Datei, eine aus dem Cloud-Speicher synchronisierte Datei, ein von der Suche ausgeschlossener Ordner –, findet die Bedingung nichts, obwohl der Text unverändert im Dokument steht. Noodlesofts eigenes Support-Forum nennt die Lösung direkt: Stellen Sie die Regel auf Contents Contain Match um, das liest die Datei selbst und umgeht Spotlight vollständig. Das ist langsamer. Noodlesoft sagt das ganz offen. Langsamer und korrekt schlägt schnell und falsch.

Diese eine Änderung löst die meisten Fälle in unter einer Minute. Der Rest dieses Artikels erklärt, warum das Problem überhaupt auftritt, nennt drei weitere Prüfungen für den Fall, dass der Bedingungswechsel allein nicht reicht, und zeigt, wo Hazels Inhaltserkennung jeder Alternative überlegen bleibt, File Arbor eingeschlossen.

Warum stoppt Hazels „Contents Contain" das Matching?

Hazel hat zwei getrennte Bedingungen, um den Inhalt einer Datei zu prüfen, und sie arbeiten grundlegend unterschiedlich. Contents Contain fragt Spotlight, ob ein Wort in einer Datei vorkommt – die Datei selbst wird dabei nie geöffnet. Contents Contain Match öffnet die Datei und durchsucht den Text direkt.

Das ist ein vernünftiges Design. Spotlights Index ist schnell, und meistens auch korrekt. Das Problem ist die Lücke zwischen „die Datei existiert" und „Spotlight hat die Datei fertig indiziert". Eine Datei, die vor ein paar Sekunden in einen überwachten Ordner gelangt ist, ist möglicherweise noch nicht durchsuchbar. Eine aus iCloud Drive, Dropbox oder OneDrive synchronisierte Datei kann minutenlang unindiziert bleiben, besonders mitten im Download oder bei einem Sync-Client im Beta-Status. Eine Datei auf einem externen Laufwerk, einer Netzwerkfreigabe oder alles, was unter macOS' Spotlight-Privatsphäre-Ausschlüsse fällt, taucht in einer Spotlight-Suche gar nicht erst auf – Contents Contain sieht sie also ebenfalls nicht, egal wie oft die Regel läuft.

Nichts davon ist ein Fehler in Ihrer Regel. Die Regel prüft einen Index, und dieser Index hinkt hinterher. Hazel führt die Regel jedes Mal korrekt aus – sie bekommt von Spotlight nur ein „Nein", wo die ehrliche Antwort „noch nicht" wäre.

Die eigentliche Lösung: Wechsel zu „Contents Contain Match"

Öffnen Sie die Regel, suchen Sie die Inhaltsbedingung und ändern Sie das Auswahlmenü von Contents Contain auf Contents Contain Match. Das ist für die meisten Nutzer bereits die vollständige Lösung, und es ist genau die, zu der Noodlesofts Forum greift, sobald jemand einen Match-Fehler meldet, der sich als Indizierungslücke herausstellt.

Contents Contain Match fragt Spotlight überhaupt nichts. Es öffnet die Datei, extrahiert den Text und durchsucht ihn in dem Moment, in dem die Regel läuft. Es gibt keinen Index, der hinterherhinken könnte, keine Ausschlussliste, an der man scheitert, kein Warten auf einen Hintergrundprozess. Die Kosten sind die Geschwindigkeit – eine Datei direkt zu lesen dauert länger als einen Lookup-Index zu prüfen –, aber bei den meisten Downloads- oder Dokumente-Ordnern werden Sie diesen Unterschied nicht bemerken.

Pflegen Sie Dutzende Regeln, die alle Contents Contain nutzen, müssen Sie diese nicht von Grund auf neu bauen. Öffnen Sie jede einzeln, ändern Sie das eine Auswahlmenü, speichern Sie. Bei einer großen Regel-Bibliothek ist das mühsam, aber eine mechanische Änderung, kein Redesign.

Drei weitere Prüfungen, bevor Sie alle Regeln neu aufbauen

Der Wechsel zu Contents Contain Match behebt das Symptom. Wollen Sie wissen, warum Spotlight die Datei überhaupt übersehen hat – oder möchten Sie die schnellere Bedingung dort behalten, wo sie sicher ist –, decken diese drei Prüfungen den Rest der realen Ursachen ab.

1. Den betroffenen Ordner neu indizieren. Suchen Sie über Spotlight oder ein Finder-Fenster nach einem Wort aus der Datei. Taucht die Datei dort nicht auf, hat Spotlight sie tatsächlich noch nicht indiziert. Apple dokumentiert eine gezielte Lösung: Fügen Sie den Ordner der Spotlight-Privatsphäre-Liste hinzu, warten Sie einige Sekunden, und entfernen Sie ihn wieder. Spotlight wertet das Entfernen als Signal, den Ordner von Grund auf neu zu indizieren – schneller, als ein ganzes Laufwerk neu zu indizieren.
2. Die Ausschlussliste selbst prüfen. Öffnen Sie Systemeinstellungen → Spotlight → Suchprivatsphäre (unter älterem macOS: Systemeinstellungen → Spotlight → Privatsphäre) und bestätigen Sie, dass der überwachte Ordner – sowie jeder übergeordnete Ordner, jedes externe Laufwerk oder Netzlaufwerk, auf dem er liegt – dort nicht bereits ausgeschlossen ist. Ein Ordner landet auf dieser Liste manchmal aus Versehen, besonders nach einer Wiederherstellung aus dem Backup oder einem Umzug auf einen neuen Mac.
3. Prüfen, ob die Datei überhaupt eine Textebene hat. Öffnen Sie das PDF in der Vorschau und versuchen Sie, eine Textzeile mit gedrückter Maustaste zu markieren. Lässt sich nichts markieren, gibt es keine Textebene zu durchsuchen – das Dokument ist ein gescanntes Bild oder ein Foto, und keine der beiden Hazel-Bedingungen wird es ohne OCR matchen, ein separates Feature, das im nächsten Abschnitt behandelt wird.

Was kann Hazel 6, das File Arbor nicht kann?

Das sollte klar gesagt werden, weil es die ehrliche Antwort ist: Bestehen Ihre Dateien überwiegend aus verschlüsselten PDFs, ist Hazel für diese Aufgabe das bessere Werkzeug, und nichts im Folgenden ändert daran etwas.

Hazel 6 hat eine automatische Texterkennung ergänzt – Noodlesofts eigene Dokumentation beschreibt sie als OCR, das „auf Bildern (und auf PDFs, die noch keine Textebene enthalten)" läuft, bevor eine Regel den Abgleich versucht. Das bedeutet: Eine gescannte Rechnung oder das Handyfoto eines Kassenbons, also etwas ganz ohne extrahierbaren Text, kann trotzdem eine Hazel-Regel erfüllen. Hazel 6 hat außerdem die Möglichkeit ergänzt, für ein verschlüsseltes PDF ein Passwort anzugeben, sodass ein gesperrtes Dokument nicht einfach stillschweigend scheitert.

Vor 1.3.0 konnte File Arbor beides nicht. Seitdem führt eine Pro-Regel, die so eingestellt ist, dass sie auch gescannte Dokumente liest, OCR auf gescannten PDFs sowie auf JPEG-, PNG- und TIFF-Bildern aus und liest dabei jeweils die erste und letzte Seite. Passwortgeschützte PDFs bleiben unerreichbar – es gibt keine Passwortoption –, und das ist eine echte Lücke, keine Randnotiz. Es ist der klarste Grund, warum ein Mac-Nutzer mit verschlüsselten Dokumenten bei Hazel bleiben sollte, statt zu wechseln.

„Contents Contain" vs. „Contents Contain Match" im Überblick

Wo File Arbor passt – und wo nicht

Was Sie eigentlich hierher geführt hat, ist wahrscheinlich der Wunsch nach derselben Art von Inhaltsregel ohne Spotlight-Abhängigkeit im Kopf – und genau dort steht File Arbor näher an Contents Contain Match als an Contents Contain. Seine Bedingung „Inhalt enthält" – ein Pro-Feature – liest den Text einer Datei direkt, ohne jeden Suchindex dazwischen, auf beiden Betriebssystemen, auf denen es läuft. Eine Regel, die nach Nurnberg sucht, matcht auch Nürnberg, denn der Abgleich ignoriert Groß-/Kleinschreibung und Akzente, und sie läuft unter Windows genauso wie unter macOS. Sie liest PDFs mit Textebene, DOCX-Dateien und reinen Text und seit 1.3.0 gescannte PDFs und Fotos, wenn die Regel so eingestellt ist, dass sie diese liest, aber dieselben Lücken gelten wie überall sonst bei Inhaltsabgleich: keine Tabellenkalkulationen, keine DOCX-Kopf- oder Fußzeilen, keine verschlüsselten PDFs.

Genau dieser letzte Punkt ist der eigentliche nennenswerte Unterschied. Hazels Inhaltsbedingungen gibt es nur unter macOS. File Arbors gibt es plattformübergreifend – dieselbe Regel, ein überwachter Ordner, unter Windows oder Mac, aus einer einzigen App. Für einen reinen Mac-Workflow ist das kein Grund zu wechseln; Hazel deckt bereits ab, was Sie brauchen, und mehr davon, sobald verschlüsselte PDFs ins Spiel kommen. Relevant wird es erst, wenn Sie zusätzlich Regeln auf einem Windows-Rechner pflegen und diese matchen sollen.

Es lohnt sich außerdem, präzise zu sein, was File Arbors Inhaltsbedingungen tun: Sie entscheiden ausschließlich über einen Zielordner, sonst nichts. Text aus einem Dokument in einen neuen Dateinamen zu übernehmen, ist eine eigene Pro-Funktion, die in 1.3.0 hinzugekommen ist: Sie klicken einen Wert wie ein Rechnungsdatum einmal in einem Beispieldokument an, und die Regel bildet daraus den Dateinamen und die Ordner. Hazel kann das ebenfalls, mit einem erfassten Match-Token. Einen breiteren Blick darauf, was inhaltsbasierte Ablage kann und nicht kann, finden Sie in unserem Leitfaden zum Sortieren von Dateien nach Inhalt.

Welche Lösung sollten Sie zuerst versuchen?

„Meine Regel hat gestern gematcht und heute plötzlich nicht mehr, gleicher Ordner, gleiche Dateien." Stellen Sie diese Regel zuerst auf Contents Contain Match um. Das ist fast immer eine Indizierungslücke, und die Match-Variante umgeht sie vollständig.

„Die Datei liegt auf OneDrive, Dropbox oder einem externen Laufwerk." Prüfen Sie zuerst Spotlight-Privatsphäre für dieses Laufwerk. Cloud-Sync-Clients und externe Laufwerke landen am häufigsten unabsichtlich auf der Ausschlussliste.

„Ich habe den Text selbst aus dem PDF kopiert, er steht definitiv drin." Schließen Sie als Nächstes die Textebene aus – der Markiertest in der Vorschau dauert zehn Sekunden und zeigt sofort, ob OCR das eigentlich fehlende Puzzlestück ist.

„Ich habe gescannte Dokumente oder passwortgeschützte PDFs, und nichts davon trifft auf mich zu." Bleiben Sie bei Hazel und nutzen Sie dessen OCR- und Passwort-Optionen. Ein Spotlight-Fix bringt Sie nicht dorthin, und File Arbor Pro liest zwar seit 1.3.0 Scans, kann aber keine passwortgeschützten PDFs öffnen – das ist Hazels echter Vorteil, und dieser Artikel kann Ihnen den nicht ausreden.

„Ich will dieselbe Inhaltsregel auch auf einem Windows-Rechner." Genau dann lohnt sich ein Blick auf File Arbor – nicht als Hazel-Ersatz, sondern als Weg, eine äquivalente Regel auf einer zweiten Plattform laufen zu lassen, die Hazel nicht erreicht.

Content-Regeln dauerhaft zuverlässig halten

Setzen Sie standardmäßig auf Contents Contain Match für jede Regel, die einen Ordner überwacht, der mit einem Cloud-Speicher synchronisiert oder auf einem Wechseldatenträger liegt – die geringen Geschwindigkeitskosten lohnen sich, um sich nie wieder zu fragen, ob Spotlight aufgeholt hat. Reservieren Sie schlichtes Contents Contain für Ordner auf Ihrem internen Hauptlaufwerk, bei denen Sie bestätigt haben, dass die Indizierung Schritt hält – dort ist es die schnellere Option, wenn der Index tatsächlich aktuell ist.

Testen Sie eine neue Inhaltsregel an einer Datei, von der Sie bereits wissen, dass sie matcht, bevor Sie ihr bei neuen Dateien vertrauen. Eine Regel, die stillschweigend nichts tut, fällt deutlich schwerer auf als eine Regel, die auslöst, wenn sie es nicht sollte – und Inhaltsbedingungen sind genau die Art von Regel, die stillschweigend scheitert, wenn die zugrunde liegende Textextraktion, ob durch Spotlight oder durch einen direkten Lesevorgang, leer ausgeht.

FAQ

Warum matcht Hazels Contents-Contain-Bedingung meine Dateien nicht?

Contents Contain durchsucht den Spotlight-Index, nicht die Datei selbst. Hat Spotlight eine Datei noch nicht indiziert – weil sie neu ist, aus einem Cloud-Speicher synchronisiert wurde, auf einem externen Laufwerk liegt oder der Ordner in Spotlights Privatsphäre-Liste ausgeschlossen ist –, findet die Bedingung nichts, obwohl der Text eindeutig in der Datei steht. Noodlesofts eigenes Forum bestätigt das als häufigste Ursache.

Was ist der Unterschied zwischen Contents Contain und Contents Contain Match in Hazel?

Contents Contain prüft den Spotlight-Index und ist schnell. Contents Contain Match liest die Datei direkt und ist langsamer, hängt dafür aber überhaupt nicht von Spotlight ab. Noodlesoft empfiehlt die zweite Option immer dann, wenn die erste eine Datei übersieht, die sie eigentlich finden müsste – ein direkter Lesevorgang lässt sich von einem veralteten oder unvollständigen Index nicht täuschen.

Wie behebe ich das Problem, dass Hazels Contents Contain nicht funktioniert?

Öffnen Sie die Regel und ändern Sie die Bedingung von Contents Contain auf Contents Contain Match – das ist Noodlesofts eigene empfohlene Lösung, und sie funktioniert, weil die Match-Variante den Text direkt aus der Datei liest, statt sich auf Spotlight zu verlassen. Hilft das nicht, prüfen Sie, ob Spotlight den Ordner tatsächlich indiziert hat und ob die Datei überhaupt eine echte Textebene besitzt, statt nur ein gescanntes Bild zu sein.

Kann Hazel gescannte PDFs oder fotografierte Dokumente lesen?

Ja, seit Hazel 6. Noodlesoft hat eine automatische Texterkennung ergänzt, die vor dem Abgleich OCR auf Bildern und auf PDFs ohne vorhandene Textebene ausführt, dazu die Möglichkeit, für verschlüsselte PDFs ein Passwort anzugeben. Frühere Hazel-Versionen und die meisten regelbasierten Wettbewerber können eine Datei ohne jede Textebene nicht lesen; File Arbor Pro kann das seit 1.3.0, hat aber keine Passwortoption.

Hat File Arbor dieselbe Spotlight-Abhängigkeit wie Hazel?

Nein. File Arbors Inhaltsbedingungen lesen den Text einer Datei direkt, genau wie Hazels Contents Contain Match, es gibt also keinen Suchindex, der veraltet sein oder einen Ordner ausschließen könnte. Der Kompromiss ist derselbe, den Hazel für seine eigene Direktlese-Option in Kauf nimmt: Eine Datei zu lesen ist langsamer als einen Index zu prüfen, hängt aber nie davon ab, ob Spotlight die Datei schon erfasst hat.

Kann File Arbor Hazel bei OCR oder verschlüsselten PDFs ersetzen?

Bei Scans ja, seit 1.3.0, wobei File Arbor Pro nur die erste und letzte Seite liest; bei verschlüsselten PDFs nein. File Arbor kann kein passwortgeschütztes PDF öffnen, ein verschlüsseltes Dokument erfüllt also nie eine Inhaltsregel in File Arbor. Hazel 6 beherrscht beides. Bestehen Ihre Dateien überwiegend aus verschlüsselten PDFs, ist Hazel die bessere Wahl; File Arbors Vorteil ist, dieselben Inhaltsregeln unter Windows und Mac auszuführen, ohne von Spotlight abhängig zu sein.

Das Fazit

Hazels Contents-Contain-Bedingung ist nicht kaputt – sie beantwortet nur ehrlich, was Spotlight bereits indiziert hat, und das ist nicht immer dasselbe wie das, was tatsächlich in der Datei steht. Stellen Sie die Regel auf Contents Contain Match um, und die Spotlight-Lücke verschwindet vollständig. Gehören verschlüsselte PDFs zu Ihrem Workflow, leistet die Passwort-Unterstützung von Hazel 6 etwas, das derzeit kein Spotlight-Fix und keine File-Arbor-Regel leisten kann.

Führen Sie zusätzlich Dateien unter Windows und wollen dort dieselbe Art von Inhaltsregel, reicht File Arbors kostenlose Stufe, um eine Regel an Ihren eigenen Dateien zu testen, bevor Sie entscheiden, ob sie sich neben Hazel lohnt – nicht anstelle davon. Unter Preise finden Sie, was die Pro-Stufe mit ihren Inhaltsbedingungen bietet.