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 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...
Other related articles and discussions:
to top