.Trashes, .fseventsd, and .Spotlight-V100

Merely plugging a removable drive into a mac (when it has write access) makes OS/X think it can take the liberty to write a lot of hidden garbage onto that disk. If you want to stop this from happening, you have to put some special files on that disk before you plug it in.

To stop OS/X from doing Spotlight indexing, you need a file called .metadata_never_index in the root directory of the removable drive.

To stop OS/X from making a .Trashes directory, you need to make your own file that *isn’t* a directory and call it .Trashes

To keep it from doing logging of filesystem events on the drive, you need to make a directory called .fseventsd and inside that folder put a single file named no_log

The contents of these files don’t matter, so you can make them empty files using touch. Even better, you could make it a text file with a link to this post, so that you (or someone else) wandering across the files will know what they’re for.

Apple’s choice to do this is incredibly self-serving and shameful. At bare minimum, hidden files and features like these should be off by default for any non-mac-only filesystem formats. They should only be enabled when the user has been made aware of them.

11 Responses to “.Trashes, .fseventsd, and .Spotlight-V100”

  1. David W Says:

    I’d like to share with you the story of a botched backup software installation, a lost partition table/boot sector, untold hours spend relearning enough about hard disks, partition tables, FAT filesystems, etc., to locate the start of the second partition (which happened to be close on disk to where an older partition used to live).

    Partition table finally reconstructed, I plug it into my Mac. Having clicked on the first file it’s clear there is something still terribly wrong with the drive - it seems I’ve created the partition table to point at one of the old ‘nearby’ filesystems, rather than the most recent one.

    Ordinarily, simply updating the start of partition +3mb or so would have been all required, but OS X had kindly created all the files you mentioned above - clobbering to death the second partition image.

    Never, ever, ever, use OS X for recovery. These are toy computers for toy people, that do toy things when you least expect it.. like writing to a f**king disk without asking. Lesson learned.

  2. Jeremy Friesner Says:

    Actually, many unix systems will write to a mounted disk automatically, unless you mount the fs with the -noatime flag. I think if you mount the disk read/write, that’s giving the OS permission to write to the disk. If you don’t want it to do that (e.g. Because the fs integrity is damaged) the you need to be sure to mount it read only.

    Apple’s focus is rightly on providing the best user experience to the non-technical user. People trying to rescue hosed filesystems or avoid harmless dot-files are a special niche, and a secondary concern at best.

  3. W^L+ Says:

    @Jeremy:
    It is certainly true that most unix-like operating systems AND WINDOWS will automatically write to a file system. However, file system recovery is a basic operation common to ALL operating systems. If the default behavior of Mac OSX prevents recovery, then it is simply the wrong action.

    It really is not hard to wait and see whether the user is trying to perform actions that require those added files to be there.

    As a Linux user, I am often called upon to recover data for Windows users. Mac users probably get just as many requests. If the OS trashes the drive before one can perform the recovery, then the above comments about not being acceptable for serious usage are true.

  4. adam Says:

    Awesome! Thanks for this post. I have no proof, but I suspect these were screwing up my RAID. Incidentally, I have my RAID drive added to be excluded from both Time Machine and Spotlight, yet these directories are still created and contain loads of data.

  5. Jim Knoble Says:

    Folks connecting external drives to a Mac should mount them read-only if they don’t want them written to (just like a savvy user would ‘mount -r’ or ‘mount -o ro’ under Linux). Here’s a prefpane (”ReadOnlyMounter”) that helps with that:

    http://homepage3.nifty.com/extant/MacOSXsoft/MacOSXsoft.html

    I agree, the use of .Cruftiness to tell Spotlight and fseventsd and Finder not to drop crap on my drives is irritating. I use these to help with that:

    http://www.zeroonetwenty.com/blueharvest/
    http://myhowto.org/mac-os-x/52-disabling-spotlight-in-os-x-leopard-for-the-removable-drives/

    To be honest, I’d rather live with this stuff than with Windows Vista constantly rearranging my desktop icons and resetting my folder views on its whim, because it thinks one file is a photograph, so therefore the whole folder must contain photos and i must want to view them as tiles, even though every other bleeding time i viewed the folder i viewed it as a Detailed List. At least Apple makes it possible to turn it off….

  6. jcast Says:

    Thanks very much for this info. Extremely helpful and nice to know I can stop annoying things from happening in circumstances where another or specialized system tries to do things with these files that it shouldn’t do.

  7. Randy Steer Says:

    Thanks! I just noticed those files/folders on a flash drive that had I most recently used with a borrowed laptop (Win XP Pro) while on vacation. I thought the laptop had been infected, since it had outdated anti-virus and no firewall. (It came from my girlfriend’s office and she didn’t want me putting on any of the GOOD security tools I use.)

    BUT, having read this, I remember that the day before the vacation, I had been in a computer store and had plugged the flash drive into a MacBook on sale, to see if it could transparently read my existing files. So that’s how I got these stupid things! I can stop writing my long e-mail to my girlfriend about how her office laptop may be infected…

    (I was checking out the MacBook because with slightly dropping Apple prices and the rare sale, the MacBook was “only” $200 more than comparable WinXP and Win7 notebooks. (Comparable except for the Mac’s dinky 13 inch screen, that is, but I guess that contributes to the long battery life.)

    I’m going to put the files you recommend on all my flash and USB drives just in case I ever plug any of them into a Mac again.

    Oh, there is one other thing that the MacBook wrote on the flash drive that you didn’t mention in your blog: a file (not folder) in the root called “._.Trashes”.

  8. Hostile Fork Says:

    Oh, there is one other thing that the MacBook wrote on the flash drive that you didn’t mention in your blog: a file (not folder) in the root called “._.Trashes”.

    Hi Randy; I didn’t see that particular file in my case. But Googling for “._.Trashes” shows you’re not alone.

    As a general concept, the ._ prefix is explained here:

    http://www.westwind.com/reference/OS-X/invisibles.html

    “These files are created on volumes that don’t natively support full HFS file characteristics (e.g. ufs volumes, Windows fileshares, etc). When a Mac file is copied to such a volume, its data fork is stored under the file’s regular name, and the additional HFS information (resource fork, type & creator codes, etc) is stored in a second file (in AppleDouble format), with a name that starts with “._”. (These files are, of course, invisible as far as OS-X is concerned, but not to other OS’s; this can sometimes be annoying…)”

  9. Randy Steer Says:

    Thanks. I’ve never really understood why MacOS “speak with forked tongue” — seems an unnecessary complication, like the Windows Registry. (Dear Windows: If a program needs configuration data, store it in a damn file in the program directory!)

    I guess the extra “._” files make sense for cross-file-format compatibility though.

  10. Jake Says:

    Putting .metadata_never_index doesn’t stop Spotlight from indexing the drive on my Snow Leopard OS. Added the volume to the Privacy tab doesn’t work either because it is removed once the drive is ejected and doesn’t reappear in the Privacy tab once the drive is re-inserted.

  11. Hostile Fork Says:

    @Jake - Hmmm… it worked for me with a FAT32 device. What filesystem is the drive in question?

Leave a Reply


Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported