#define private public - "Disk FOO wasn't ejected because one or more programs may be using it!" (25 Oct 2015)

"Disk FOO wasn't ejected because one or more programs may be using it!" (25 Oct 2015)

I had seen that pesky message every now and then before, but today I finally got fed up with it, as I was pretty sure that no application was running which had a legitimate business touching the external drive - at least none of the applications I had started myself. So I set out on a quest to find the culprit.

The weapon of choice in such a case is lsof:

  sudo lsof | grep /Volumes/FOO

In my case, this produced a list of files opened by a process called mds_store which, apparently, is used to produce the Spotlight search index:

mds_store 42059            root  txt       REG                1,6       3277  8832664 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexGroups
mds_store 42059            root  txt       REG                1,6      32768  8832663 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexIds
mds_store 42059            root  txt       REG                1,6       8192  8832666 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexTermIds
mds_store 42059            root  txt       REG                1,6       8192  8832668 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexPositionTable
mds_store 42059            root  txt       REG                1,6       8224  8832669 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexDirectory
mds_store 42059            root  txt       REG                1,6       1024  8832670 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexCompactDirectory
mds_store 42059            root  txt       REG                1,6      65536  8832671 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/live.0.indexArrays
mds_store 42059            root    5r      DIR                1,6       2074  8832643 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842
mds_store 42059            root   11r      DIR                1,6       2074  8832643 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842
mds_store 42059            root   47u      REG                1,6         28  8832650 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/indexState
mds_store 42059            root   49u      REG                1,6     118784  8832674 
  /Volumes/FOO/.Spotlight-V100/Store-V2/A75D8EF4-8412-4A13-8775-A52C20F05842/.store.db
backupd   42148            root    4w      REG                1,6       1300  8832803
  /Volumes/FOO/Backups.backupdb/Claus/2015-10-25-175619.inProgress/.Backup.467484979.422497.log

The fun part was that I had explicitly configured Spotlight to ignore that particular external disk - and yet, it was still trying to index it!

Turns out that I am not alone with this. "Disable Spotlight on a FAT32 external drive" provides the best summary I could find. Apparently, the type of file system on the external drive plays a role. I was somewhat skeptical about this claim, but then, all my external drives had FAT32 file systems on them, and so I followed the instructions in the article. I was still somewhat incredulous, as as this seemed to be such a basic issue and the article is rather old.

But then, following the instructions indeed seemed to be successful, at least initially. The magic ingredient in the sauce was to create a top-level file called .metadata_never_index on the affected drive:

touch /Volumes/FOO/.metadata_never_index

I was too impatient to wait for existing instances of mds_store to finish their work, and did not care about the consistency of the Spotlight index on the external drive anyway. So I killed the mds_store process right away, then unplugged the drive and plugged it in again. From there, indeed I had no issues anymore with ejecting the external disk. Hmmm...