Hazel Contents Contain Çalışmıyor: Nedeni ve Çözümü

Hazel'ın Contents Contain koşulu çalışmıyorsa önce neyi okuduğuna bakın: dosyanın kendisine değil, Spotlight'ın o dosya hakkındaki dizinine. Spotlight bir şeyi dizinlememişse — yeni bir dosya, buluttan senkronize edilen bir dosya, aramadan dışlanmış bir klasör — koşul hiçbir şey bulamaz, metin belgenin içinde apaçık dursa bile.

Noodlesoft'un kendi destek forumu çözümü doğrudan veriyor: kuralı Contents Contain Match'e çevirin, bu seçenek dosyayı kendisi okur ve Spotlight'ı tamamen atlar. Daha yavaştır. Noodlesoft bunu açıkça söylüyor. Yavaş ve doğru, hızlı ve yanlıştan iyidir.

Bu düzeltme çoğu durumu bir dakikadan kısa sürede çözer. Yazının geri kalanı sorunun neden oluştuğunu, koşulu değiştirmek tam çözmezse kontrol etmeye değer üç şeyi ve Hazel'ın içerik eşleştirmede hâlâ her alternatiften — File Arbor dahil — önde olduğu yeri anlatıyor.

Hazel'ın "Contents Contain" Koşulu Neden Eşleşmeyi Bırakır?

Hazel'da bir dosyanın içindekini kontrol eden iki ayrı koşul var ve bunlar tamamen farklı çalışıyor. Contents Contain, Spotlight'a bir kelimenin dosyada geçip geçmediğini sorar — dosyayı hiç açmaz. Contents Contain Match ise dosyayı açar ve metni doğrudan arar.

Bu makul bir tasarım. Spotlight'ın dizini hızlı ve çoğu zaman doğru. Sorun, "dosya var" ile "Spotlight dosyayı dizinlemeyi bitirdi" arasındaki boşluk. İzlenen bir klasöre birkaç saniye önce düşen bir dosya henüz aranabilir olmayabilir. iCloud Drive, Dropbox veya OneDrive'dan senkronize edilen bir dosya, özellikle indirme sırasında veya beta durumundaki bir senkron istemcisinde, dakikalarca dizinlenmeden kalabilir. Harici bir sürücüdeki, bir ağ paylaşımındaki veya macOS'un Spotlight Gizlilik dışlamalarının kapsadığı herhangi bir dosya, Spotlight aramasında hiç görünmez — bu da kural kaç kez çalışırsa çalışsın Contents Contain'in de onu göremeyeceği anlamına gelir.

Bunların hiçbiri kuralınızdaki bir hata değil. Kural bir dizini kontrol ediyor ve geride kalan dizin. Hazel kuralı her seferinde doğru çalıştırıyor; sadece dürüst cevap "henüz değil" olduğunda Spotlight'tan "hayır" cevabı alıyor.

Gerçek Çözüm: Contents Contain Match'e Geçin

Kuralı açın, içerik koşulunu bulun ve açılır menüyü Contents Contain'den Contents Contain Match'e çevirin. Çoğu kişi için düzeltmenin tamamı bu, ve bir eşleşme hatasının aslında bir dizinleme boşluğu olduğu ortaya çıktığında Noodlesoft'un forumunun her seferinde başvurduğu şey de bu.

Contents Contain Match, Spotlight'a hiçbir şey sormaz. Dosyayı açar, metni çıkarır ve kural çalıştığı an arar. Geride kalan bir dizin yok, takılacak bir dışlama listesi yok, arka planda bir işlemin yetişmesini bekleme yok. Bedeli hız — bir dosyayı doğrudan okumak bir arama tablosuna bakmaktan daha uzun sürer — ama çoğu İndirilenler veya Belgeler klasörü hacminde bu fark fark edilecek bir şey değil.

Hepsi Contents Contain kullanan onlarca kuralı yönetiyorsanız, bunları sıfırdan yeniden kurmanıza gerek yok. Her birini açın, tek açılır menüyü değiştirin ve kaydedin. Büyük bir kural kitaplığı için yorucudur, ama bir yeniden tasarım değil, mekanik bir düzenlemedir.

Her Şeyi Yeniden Kurmadan Önce Üç Kontrol Daha

Contents Contain Match'e geçmek belirtiyi düzeltir. Spotlight'ın dosyayı neden ilk baştan kaçırdığını öğrenmek istiyorsanız — ya da güvenli olduğu yerlerde daha hızlı koşulu korumak istiyorsanız — bu üç kontrol gerçek dünyadaki nedenlerin geri kalanını kapsıyor.

1. İlgili klasörü yeniden dizinleyin. Dosyadan bildiğiniz bir kelimeyi Spotlight veya bir Finder penceresiyle arayın. Dosya çıkmıyorsa, Spotlight onu gerçekten henüz dizinlememiştir. Klasörü Spotlight Gizlilik listesine ekleyip birkaç saniye bekleyip tekrar kaldırarak hedefli bir düzeltme uygulayın — Spotlight bu kaldırmayı o klasörü sıfırdan yeniden dizinleme sinyali olarak alır, ki bu tüm bir birimi yeniden dizinlemekten daha hızlıdır.
2. Gizlilik dışlama listesinin kendisini kontrol edin. Sistem Ayarları → Spotlight → Arama Gizliliği'ni açın (eski macOS sürümlerinde Sistem Tercihleri → Spotlight → Gizlilik) ve izlenen klasörün — ve üzerinde bulunduğu üst klasör, harici sürücü veya ağ biriminin — zaten dışlanmış olmadığını doğrulayın. Bir klasör buraya kazara düşebilir, özellikle bir yedekten geri yükleme veya yeni bir Mac'e geçiş sonrasında.
3. Dosyanın gerçekten bir metin katmanı olduğunu doğrulayın. PDF'i Önizleme'de açın ve bir metin satırı boyunca tıklayıp sürüklemeyi deneyin. Hiçbir şey vurgulanmıyorsa aranacak bir metin katmanı yoktur — belge taranmış bir görüntü veya bir fotoğraftır ve OCR olmadan Hazel'ın hiçbir koşulu onu eşleştirmez, ki bu bir sonraki bölümün konusu.

Hazel 6 Neler Yapabiliyor, File Arbor Yapamıyor?

Açıkça söylemeye değer, çünkü dürüst cevap bu: dosyalarınız çoğunlukla şifreli PDF'lerden oluşuyorsa, bu iş için daha iyi araç Hazel'dır ve aşağıdaki hiçbir şey bunu değiştirmez.

Hazel 6, Noodlesoft'un kendi belgelerinin "görüntülerde (ve zaten bir metin katmanı içermeyen PDF'lerde)" bir kural eşleştirmeyi denemeden önce çalışan OCR olarak tanımladığı anlık metin tanımayı ekledi. Bu, taranmış bir fatura veya bir makbuzun telefon fotoğrafının — gerçekten çıkarılabilir hiçbir metni olmayan bir şeyin — hâlâ bir Hazel kuralıyla eşleşebileceği anlamına geliyor. Hazel 6 ayrıca şifreli bir PDF için parola sağlama yeteneğini de ekledi, böylece kilitli bir belge sessizce başarısız olmuyor.

File Arbor 1.3.0'dan önce ikisini de yapmıyordu. O zamandan beri, taranmış belgeleri de okuyacak şekilde ayarlanmış bir Pro kuralı, taranmış PDF'lerde ve JPEG, PNG ve TIFF görüntülerde OCR çalıştırır ve her birinin ilk ve son sayfasını okur. Parola korumalı PDF'ler hâlâ erişilemez — parola seçeneği yok — ve bu gerçek bir boşluk, küçük bir dipnot değil. Şifreli belgeleri olan bir Mac kullanıcısının geçiş yapmak yerine Hazel'da kalması gereken en net neden bu.

Bir Bakışta: Contents Contain vs Contents Contain Match

File Arbor Nerede İşe Yarar, Nerede Yaramaz

Sizi buraya asıl getiren şey Spotlight'ı hiç düşünmeden aynı türde bir içerik kuralı istemekse, File Arbor'ın Contents Contain'den çok Contents Contain Match'e yakın durduğu yer tam olarak bu. Pro katmanına özgü "içerik içeriyor" koşulu, dosyanın metnini doğrudan okur — çalıştığı iki işletim sisteminden hiçbirinde araya giren bir arama dizini yok. bogazici ile eşleşen bir kural Boğaziçi yazan bir dosyayı da yakalar, çünkü karşılaştırma büyük/küçük harf ve aksan farkı gözetmez, ve Windows'ta da macOS'ta da aynı şekilde çalışır. Metin katmanı olan PDF'leri, DOCX dosyalarını ve düz metni, 1.3.0'dan itibaren de kural okumaya ayarlıysa taranmış PDF'leri ve fotoğrafları okur, ama içerik eşleştirmenin her yerde geçerli olan aynı boşluk listesi burada da geçerli: elektronik tablo yok, DOCX üst bilgisi, alt bilgisi veya dipnotu yok, şifreli PDF yok.

Asıl adlandırmaya değer fark bu son kısım. Hazel'ın içerik koşulları yalnızca macOS'ta. File Arbor'unkiler çapraz platform — aynı kural, bir klasörü izleyen, Windows'ta veya Mac'te, tek bir uygulamadan. Yalnızca Mac'te çalışan bir iş akışı için bu, geçiş yapmak için bir neden değil; Hazel zaten ihtiyacınız olanı yapıyor, şifreli PDF'ler devreye girince daha da fazlasını yapıyor. Yalnızca Windows'ta bir makinede de kurallar tutmak ve bunların eşleşmesini istiyorsanız önemli oluyor.

File Arbor'un içerik koşullarının tam olarak ne yaptığını da netleştirmekte fayda var: yalnızca bir hedef klasöre karar verirler, başka hiçbir şeye. Bir belgeden metin çekip yeni bir dosya adına koymak ayrı bir Pro özelliğidir ve 1.3.0'da eklendi: örnek bir belgede fatura tarihi gibi bir değere bir kez tıklarsınız, kural dosya adını ve klasörleri ondan oluşturur. Ayrıca Hazel bunu yapabilir, yakalanmış bir eşleşme jetonuyla. İçerik bazlı dosyalamanın araçlar arasında neleri yapıp neleri yapamadığına daha geniş bir bakış için, dosyaları içeriğine göre klasörlere ayırma rehberimize bakın.

Hangi Çözümü Önce Denemelisiniz?

"Kuralım dün eşleşiyordu, bugün eşleşmiyor, aynı klasör, aynı dosyalar." Önce o kuralı Contents Contain Match'e çevirin. Bu hemen her zaman bir dizinleme boşluğudur ve match seçeneği bunu tamamen atlar.

"Dosya OneDrive'da, Dropbox'ta veya harici bir sürücüde." Her şeyden önce o birim için Spotlight Gizlilik'i kontrol edin. Bulut senkron istemcileri ve harici sürücüler, kimse kasıtlı yapmadan bir klasörün dışlanmış hâle geldiği en yaygın yerlerdir.

"PDF'in metnini kendim kopyala-yapıştır yaptım, kesinlikle içeride." Sırada metin katmanını eleyin — Önizleme'nin metin seçme testi on saniye sürer ve OCR'ın asıl eksik parça olup olmadığını hemen söyler.

"Taranmış belgelerim veya parola korumalı PDF'lerim var, bunların hiçbiri geçerli değil." Hazel'da kalın ve OCR ile parola seçeneklerini kullanın. Bir Spotlight düzeltmesi sizi oraya götürmez ve File Arbor Pro 1.3.0'dan itibaren taramaları okusa da parola korumalı PDF'leri açamaz — bu Hazel'ın gerçek avantajı ve bu yazının sizi bundan vazgeçiremeyeceği bir şey.

"Aynı içerik kuralını bir Windows makinede de istiyorum." File Arbor'a bakmaya değer tek durum bu — Hazel'ın yerine değil, Hazel'ın ulaşamadığı ikinci bir platformda eşdeğer bir kural çalıştırmanın bir yolu olarak.

İçerik Kurallarını İleriye Dönük Güvenilir Tutmak

Buluttan senkronize olan veya çıkarılabilir ortamda yaşayan bir klasörü izleyen her kural için varsayılan olarak Contents Contain Match'i kullanın — küçük hız bedeli, Spotlight'ın yetişip yetişmediğini hiç merak etmemeye değer. Düz Contents Contain'i, dizinlemenin gerçekten güncel kaldığını doğruladığınız ana dahili sürücünüzdeki klasörler için saklayın, çünkü dizin gerçekten güncelse daha hızlı seçenek odur.

Yeni bir içerik kuralını, yeni gelenlere güvenmeden önce zaten eşleştiğini bildiğiniz bir dosyaya karşı test edin. Sessizce hiçbir şey yapmayan bir kural, yanlış zamanda tetiklenen bir kuraldan fark edilmesi çok daha zordur, ve içerik koşulları, altındaki metin çıkarma — Spotlight'ın veya doğrudan bir okumanın — boş çıktığında tam olarak sessizce başarısız olan türden kurallardır.

FAQ

Hazel'ın Contents Contain koşulu neden dosyalarımı eşleştirmiyor?

Contents Contain, Spotlight'ın dizinini arar, dosyanın kendisini değil. Spotlight bir dosyayı henüz dizinlememişse — yeni geldiği, buluttan senkronize edildiği, harici bir sürücüde olduğu ya da klasör Gizlilik listesinde dışlandığı için — koşul hiçbir şey bulamaz, metin dosyanın içinde apaçık dursa bile. Noodlesoft'un kendi forumu bunun en yaygın neden olduğunu doğruluyor.

Hazel'da Contents Contain ile Contents Contain Match arasındaki fark nedir?

Contents Contain, Spotlight'ın dizinini kontrol eder ve hızlıdır; Contents Contain Match ise dosyayı doğrudan okur, daha yavaştır ama Spotlight'a hiç bağımlı değildir. Noodlesoft, birincisi eşleşmesi gereken bir dosyayı kaçırdığında ikincisini önerir, çünkü doğrudan okuma bayat veya eksik bir dizin tarafından yanıltılamaz.

Hazel'da Contents Contain çalışmıyor sorunu nasıl düzeltilir?

Kuralı açın ve koşulu Contents Contain'den Contents Contain Match'e çevirin — bu, Noodlesoft'un kendi önerdiği çözümdür ve işe yaramasının nedeni, match seçeneğinin Spotlight'a güvenmek yerine dosyanın metnini doğrudan okumasıdır. Bu yardımcı olmazsa, Spotlight'ın klasörü gerçekten dizinlediğinden ve dosyanın taranmış bir görüntü değil gerçek bir metin katmanına sahip olduğundan emin olun.

Hazel taranmış PDF'leri veya belge fotoğraflarını okuyabilir mi?

Evet, Hazel 6'dan itibaren. Noodlesoft, eşleştirmeden önce görüntülerde ve mevcut bir metin katmanı olmayan PDF'lerde çalışan anlık metin tanıma ekledi, üstüne şifreli PDF'ler için parola sağlama seçeneği de geldi. Önceki Hazel sürümleri ve çoğu kural tabanlı rakip, hiç metin katmanı olmayan bir dosyayı okuyamaz; File Arbor Pro 1.3.0'dan itibaren okuyabilir, ancak parola seçeneği yoktur.

File Arbor'da Hazel'daki gibi bir Spotlight bağımlılığı var mı?

Hayır. File Arbor'un içerik koşulları dosyanın metnini doğrudan okur, tıpkı Hazel'ın Contents Contain Match seçeneği gibi, bu yüzden bayatlayabilecek veya bir klasörü dışlayabilecek bir arama dizini hiç devreye girmez. Bedeli Hazel'ın kendi doğrudan okuma seçeneğinin kabul ettiğiyle aynı: dosyayı okumak bir dizine bakmaktan yavaştır, ama Spotlight'ın dosyaya önce ulaşıp ulaşmadığına asla bağlı değildir.

File Arbor, OCR veya şifreli PDF'ler için Hazel'ın yerini tutabilir mi?

Taramalar için 1.3.0'dan itibaren evet, ancak File Arbor Pro yalnızca ilk ve son sayfayı okur; şifreli PDF'ler için hayır. Parola korumalı bir PDF'i açamaz, bu yüzden şifreli bir belge File Arbor'daki bir içerik kuralıyla hiçbir zaman eşleşmez. Hazel 6 ikisini de yapar. Dosyalarınız çoğunlukla şifreli PDF'lerden oluşuyorsa Hazel daha uygun araçtır; File Arbor'un avantajı aynı içerik kurallarını Windows ve Mac'te, Spotlight bağımlılığı olmadan çalıştırmasıdır.

Son Söz

Hazel'ın Contents Contain koşulu bozuk değil — Spotlight'ın dizinlediği şey hakkında dürüst bir cevap veriyor, ve bu her zaman dosyada gerçekte olanla aynı şey değil. Kuralı Contents Contain Match'e çevirin, Spotlight boşluğu tamamen ortadan kalksın. Şifreli PDF'ler iş akışınızın bir parçasıysa, Hazel 6'nın parola desteği hiçbir Spotlight düzeltmesinin ve hiçbir File Arbor kuralının şu anda yapamadığı bir şey yapıyor.

Windows'ta da dosyalarınız varsa ve orada da aynı türde bir içerik kuralı istiyorsanız, File Arbor'un ücretsiz katmanı Hazel'ın yerine değil yanına eklemeye değip değmeyeceğine karar vermeden önce kendi dosyalarınızda bir kuralı denemek için yeterli. Pro katmanının içerik koşullarının neleri kapsadığını görmek için fiyatlandırma sayfasına bakın.