Spotlight 只能搜尋檔案 - 那地址本的檔案在哪裡？

[fortepianissimo]

可能很多人都已經知道， Spotlight 是一個 file-based 的搜尋系統。舉例來說，在 Panther 的時代，放在一個信件夾裡所有的 emails 都是存放在單一個檔案裡 (mbox - 這是 UNIX 下的標準格式）。但是這樣一來當 Spotlight 搜尋你的 emails 時，不管找到的是哪些 email，它都只能告訴你該 email 是來自檔案 mbox — 一點用也沒有。

所以 Tiger Mail 在內部已經改成是一封 email 存放在一個檔案裡。瞧瞧你的

~/Library/Mail/

找找看底下的任一個 Messages 檔案夾，你就會見到成千上萬的 email 檔案 (.emlx)。

問題是，地址本的檔案在哪裡？答案是

~/Library/Caches/com.apple.AddressBook/MetaData/

iCal 呢？

~/Library/Caches/com.apple.iCal

（你可能會說，知道這有什麼用。之前我為了加快 Spotlight 的效率，把 ~/Library/Caches 加進 Spotlight 的 "隱私" 列表當中。結果發現我再也找不到某些人的連絡資料了 ）

[fortepianissimo]

可能很多人都已經知道， Spotlight 是一個 file-based 的搜尋系統。舉例來說，在 Panther 的時代，放在一個信件夾裡所有的 emails 都是存放在單一個檔案裡 (mbox - 這是 UNIX 下的標準格式）。但是這樣一來當 Spotlight 搜尋你的 emails 時，不管找到的是哪些 email，它都只能告訴你該 email 是來自檔案 mbox — 一點用也沒有。

一開始知道這個 Spotlight 的 "特點" 時 ，就覺得這種實作方式實在太急就章了一些。

Tiger 提供了應用程式界面，讓軟體開發者能夠設計自己的 "importer" — 就是任何非 Apple 公司開發的軟體，都能夠將自己程式產生的資料加以索引，加進 Spotlight 可以搜尋的範圍當中。

既然如此，為什麼不送佛送西天，讓程式開發者也能寫自己的附加模組，讓 Spotlight 在顯示搜尋結果的時候，能夠叫用開發廠商的模組來顯示結果？這樣就可以避開這種非檔案不能搜尋的限制了。

舉例來說，如果所有的 emails 都放在一個檔案裡 — importer 可以把相關資料加進 Spotlight 的 index 裡，只是找到的檔案都是指向同一個檔案 — 譬如叫做 mbox。如果廠商能開發自己的 Spotlight 顯示模組，那麼這些搜尋結果：也就是同一個檔案 (mbox) 裡的不同位置，就可以透過這些模組，以一個個 icon 的方式顯現在結果視窗當中。顯示模組也可以負責解譯使用者在這些 icon 上用滑鼠雙擊的動作（譬如說用 Mail.app 來打開該 mbox 檔案的某一個位置）。

也許有我不知道的理由？

[fortepianissimo]

舉例來說，如果所有的 emails 都放在一個檔案裡 — importer 可以把相關資料加進 Spotlight 的 index 裡，只是找到的檔案都是指向同一個檔案 — 譬如叫做 mbox。如果廠商能開發自己的 Spotlight 顯示模組，那麼這些搜尋結果：也就是同一個檔案 (mbox) 裡的不同位置，就可以透過這些模組，以一個個 icon 的方式顯現在結果視窗當中。顯示模組也可以負責解譯使用者在這些 icon 上用滑鼠雙擊的動作（譬如說用 Mail.app 來打開該 mbox 檔案的某一個位置）。

也許有我不知道的理由？

想了一下，大概知道這其中的奧妙了。

Tiger 之所以會知道某個檔案被更動過，是因為 Apple 在系統核心 (kernel) 的檔案 I/O 部份作了改良 — 任何檔案動作都會立刻被核心知道，然後相對應的 importer 就會被啟動，重新索引這個被更動過的檔案。

但是檔案系統能夠知道的，只是 — 檔案罷了。任何在檔案內部的局部更動，除非應用程式合作，否則核心是無從知道的。

有一個方法也許能解決這問題：那就是 importer 在重新索引該檔案時，能夠有辦法將新檔案和舊檔案在 Spotlight index 存放的資料互作比較，決定究竟是哪一部份受過更改。當然系統作這些事需要花上額外的時間... 但是，只要應用軟體夠聰明，它應該能夠把適當的資料事先放在了 Spotlight index 裡，這樣在做檔案比對的時候，只需要比對這個 "檔案摘要" 就夠了。

結論：非 file-based 的 Spotlight 似乎還是可行（除非 Spotlight index 在資料格式上有先天限制）。

所有這些多出來的複雜手續，都是因為對作業系統的檔案系統 (filesystem) 來說，最小的單位只能是 "檔案物件"。如果想要知道 "邏輯物件" （一個檔案裡可能有多個邏輯物件，多個檔案也有可能組成一個邏輯物件） ，就必須要拐彎抹角的想辦法找出另類途徑了。

話說回來， Apple 大可以提供應用程式界面上的支援，讓一般的軟體開發者能使用小型的資料庫來存放它們的資料 （也就是說，提供一種統一的檔案格式 — 這種檔案格式能提供資料庫般的存取功能）。這樣一來，使用這些界面的程式就可以立刻獲得 "邏輯物件" 層面的 Spotlight 支援了。

[fortepianissimo]

結論：非 file-based 的 Spotlight 似乎還是可行（除非 Spotlight index 在資料格式上有先天限制）。

剛剛看到 PowerMail 5.2 的 Release notes:

"PowerMail now supports the searching of its database using SpotLight (requires Mac OS X 10.4 build 8A25 or later) in addition to its built-in, enhanced FoxTrot search engine:

If you double-click on a found item in Spotlight, it will not just open it as an orphaned document window in PowerMail but actually open the corresponding message in the database itself."

這似乎印證了之前我得到的結論。如果真是這樣，Apple 開發 Mail.app 的團隊該打屁股了。