Death to .DS_Store

December 24th, 2011
Spencer Nielsen Follow snielsen42 on Twitter

The “.DS_Store” file is an abomination and must be stopped. You know what I’m talking about. I regularly rant about how this annoying file gets in your way, dirties things up and just screws with your stuff in general. Today I decided to do something about it. Before we get to that, lets quickly review what it is and why it sucks.

What Is It?

The .DS_Store is a Finder metadata file created primarily by Mac OS X’s Because of the dot (“.”) prefix it is typically not visible in many file browsers and most Mac OS X users are probably not aware of it. It is regularly created when the Finder accesses filesystem directories. It contains directory information about icon locations, view options, silkscreen configuration and the like. The functionality that it provides is moderately useful, but becoming less and less relevant over time. In any case, a long time ago the horrible decision was made to store that Finder metadata in an actual file (.DS_Store) in the filesystem within the relevant directory. We have been paying for it ever since. Over time more and more metadata relating to files and the filesystem has been added to Mac OS X, but thankfully those have been stored in saner places (extended attributes, etc). For the time being though .DS_Store is still here with us and still causing trouble. What’s so harmful about the file you might ask?

Cross-OS Cleanliness

The .DS_Store file is only useful if you are accessing the filesystem with the Finder. What if you aren’t using the Finder though? What if you aren’t even using Mac OS X at all? At best the files then become wasted space that is ignored. At worst they are horrible clutter that dirties up your file browsing experience. It doesn’t take much online searching to find countless forum posts from Windows users asking what these files are or the innumerable removal scripts that Linux users have authored to clean them from their directories. On Mac OS X, if you insert a USB flash drive, mount a network volume or zip up a directory to give to a friend, more likely than not, .DS_Store files have hopped on for the ride. Whoever has to interact with those directories next that doesn’t use a Mac is going to have to deal with those in some way even if it just having to consciously ignore them. Eventually a power-user facing flag was added that would disable .DS_Store file creation on network volumes (“defaults write DSDontWriteNetworkStores true“) which was a good move. There are still however, plenty of reasons why Mac OS X users hate having them on their own systems.

Source Control Gunk

All the programmers in the room, raise your hand if you have ever added “.DS_Store” to your .gitignore file or equivalent source control ignore configuration? What’s that? That guy in the back who didn’t raise his hand? Oh, he was sleeping…there’s his hand. The contents of the .DS_Store file are always changing and so even if you did happen to check the .DS_Store files into your repository (furthering it’s unholy propagation) it is always going to be showing up as a changed file and gunking up your commits with changes and data that have absolutely nothing at all to do with your code. I have to wonder how many global man hours have been wasted in configuring source repos to ignore these files or cleaning them out of the repos after someone YET AGAIN added them in their latest commit.

Permissions Playtime

Because the .DS_Store file is so inconspicuous and usually innocuous, a lot of the time we simply forget it is there. Unfortunately when doing things like mass permission changes and the like, the .DS_Store file will unintentionally come along for the ride. Suppose you tighten up the permissions on a directory that has a .DS_Store in it. After a while you decide to go through an manually clean it or lower the permission levels on the contents again. You had better remember that you also raised the permissions on the .DS_Store file as well or you might be puzzled why you don’t have permission to delete the directory or why the Finder isn’t saving your directory options. It is no show stopper. Any competent command line monkey can figure it out and fix it. But again, the few minutes it takes to fix it should never have been necessary. Technology is supposed to save time, not destroy it.

So What Do We Do About It?

Those were just three examples that I thought of off the top of my head. Leave your own .DS_Store horror/annoyance stories in the comments and I will add any more that don’t generally fall under one of those three examples. So they are a time consuming annoyance, easy enough to whine about. But what to DO about it? The other day I again ranted on twitter about them and it was suggested that maybe someone could write a daemon that would listen to fsevents and nuke them on creation. I kept thinking that the evil should really be stopped at the source. The Finder. I wondered aloud what it would take to patch the Finder so that it wouldn’t even create them anymore at all. I decided that the creation of .DS_Store files needed to be stopped. Like Jack Ryan in Patriot Games I decided that “I will make it my mission in life”. For an afternoon at least. So in the interest of cleanliness I came up with a dirty hack. I call it DeathToDSStore. I have documented my investigation and development process below.

Who’s Behind This!? I Want A Name!

I initially suspected that it was solely the that was responsible for .DS_Store creation. After a little investigation it appeared like that was pretty much true but there might be other things out there that also create them. My first lead was the DSDontWriteNetworkStores setting that causes the Finder to not create the files on network mounts. I needed to find out where the code that interacted with that setting lives. Examining /System/Library/CoreServices/ with strings came up empty. It must be in a framework somewhere. Poking around /System/Library/PrivateFrameworks revealed the culprit: DesktopServicesPriv.framework. Ok so, .DS_Store authoring functionality is very likely in this framework. Clients of this framework in /System/Library/CoreServices include,,, backupd and the For the time being I was just going to concentrate on the main offender.

AKA Property Stores

I started perusing DesktopServicesPriv.framework‘s symbols using nm (piped into c++filt) to see what kind of things I had to work with. Hmm, FSVolumeInfo::ShouldWriteNetworkPropertyStores()? That sounds like it could be directly connected to DSDontWriteNetworkStores. Perusing around a little more it appears like .DS_Store files are called “Property Stores” internally. There is even a C++ HFSPlusPropertyStore class present. I had just found what I was looking for. Time to start poking at things.

I Wanna Be A mach_star

I pulled out rentzsch‘s awesome mach_star injection/overriding code and started overriding various routines in that class. For some reason I wasn’t able to use dlsym() to get the address of any C++ member functions. I tried all sorts of permutations of the mangled name that nm was giving me for stuff but nothing seemed to work. “Well, I guess I could always just plug the raw address in.” I thought. So I used vmmap Finder to get the base address of where the DesktopServicesPriv.framework‘s __TEXT section was residing in memory. If ASLR (Address Space Layout Randomization) is in play then this value can be different every launch. (EDIT UPDATE: comex reminded me about the _dyld family of routines and so this is now obtained manually at runtime instead.)

nm gave me the offsets of the functions I was targeting and so it was simple enough to just add them together to get the location of the functions I needed to override. It would obviously be a lot cleaner to be able to determine the address from within the binary at runtime but I couldn’t convince dlsym to give me anything and this was working (unfortunately it adds an external dependencies on Apple’s Developer Tools (nm) and BSD.pkg(c++filt)).


After a bit of trial and error I found that overriding HFSPlusPropertyStore::FlushChanges() with a function that simply did nothing, successfully prevented the creation of .DS_Store files on both Snow Leopard and Lion. On first inspection it doesn’t appear that overriding this function has any unintended behaviors and appears to accomplish the objective of halting .DS_Store creation quite nicely! Or about as nicely as you can when you are doing something like live patching the Finder.

(Side note: I noticed that I am not the only one using mach_star to live patch the Finder. The Dropbox daemon is doing it as well every time the Finder launches)

There’s An App For That

So I packaged my work up into an app (you can also run it through the command line under sudo with the “-silent” option) and published the source on github. In the near future I am going to add a launchd option so that it will run every time the user logs in or any time the Finder is run (EDIT UPDATE: The option to install a Launch Agent has now been added). Now that I have a solution I am going to put my money where my mouth is and start running without .DS_Store file creation full time. Hopefully I wont run into any major issues (I will report them here if I do) and I am pretty sure that I wont miss their functionality (At least by having new ones created. Existing disk images and CDs with custom layouts will still be read just fine). So far the result is pretty positive! Is this safe? Eh…. The safety/cleanliness/forward compatibility of patching OS components has been discussed and debated ad nauseum. You probably already understand the risks involved. Things look pretty stable but I make no promises. Go ahead and try out the or build your own from source if you want and let me know how it works out for you. Remember that you need to have the Developer Tools installed, BSD.pkg installed and admin authorization. Death to .DS_Store!

El Capitan Update

In OS X El Capitan, Apple introduced a new feature called System Integrity Protection (SIP) which prevents filesystem and runtime modification of the operating system. Unfortunately, this prevents the mechanism that Death To .DS_Store uses from working on the Finder process. You can disable SIP to get things working again, although a better choice might be to head over to and file a radar. You can optionally request that it be duplicated against my bug (radar://17348033) that I officially filed with Apple over the issue. I am still holding out hope that eventually Apple will do the right thing and fix their mistake.

70 Responses to “Death to .DS_Store”

  1. orta Says: – this has always worked well for me

  2. comex Says:


    Instead of using vmmap, you can use _dyld_get_image_vmaddr_slide() and related functions.

    Instead of using nm, you can use nlist().

  3. mga Says:

    and your .gitignore indeed excludes .DS_Store : )

  4. Mike Says:

    Or, rather than ranting, you could fix your busted filesystem(s) so that the information can be stored in an extended attribute. That would actually be progress…

  5. Tom Andersen Says:

    There is a call called HFSPlusPropertyStore::FlushChanges and you commented it out. Tested it on likely a single kind of HD, locally mounted, and then called ‘success’!? It is a crazy solution. It may work, but worst case could be something like data loss.

    Agreed that Apple should toss .DS_store. But hacking away something that deals with the file system and has the word ‘flush’ in it is not good.

    Also googling for DSDontWriteLocalStores suggests that it may work? Anyone try this?

    ‘This is Google’s cache of It is a snapshot of the page as it appeared on 9 Nov 2011 14:34:34 GMT. The current page could have changed in the meantime. Learn more

    Full version
    These search terms are highlighted: dsdontwritelocalstores
    Skip to content
    philosup`s thoth


    MAC 에서 “._”파일이 생길때.. 컴퓨터

    2011.04.28 11:02 philosup Edit

    .DS_Store가 생길때 처리 방법이군요. ㅜㅜ — 수정 2011/4/28 14:13

    네트워크 드라이브에 생길때
    defaults write DSDontWriteNetworkStores true

    USB드라이브에 생길때
    defaults write DSDontWriteUSBStores true

    로컬드라이브에 생길때
    defaults write DSDontWriteLocalStores true

  6. Tom Hunter Says:

    I like to add .Ds_Store to my ~/.gitignore

  7. Mature Mac User Says:

    So, let me get this straight.

    You want us to “patch” the Finder in a way that you don’t understand, but “On first inspection it doesn’t appear that overriding this function has any unintended behaviors”.

    And all of this to satisfy your anal-retentive feeling about harmless invisible files.

    One would have to be out of his mind to do it.

  8. link222 Says:

    I think a while ago there was something called Blue Harvest that would take care of it automatically for you. Check it out

  9. Okonomiyaki3000 Says:

    Is this really a big deal? A minor annoyance at best.

    Actually, there have been times when people have sent me files and there’s a .DS_Store in there somewhere. I kind of like seeing it. I get a feeling like ‘ah! a Mac user, nice choice!’

  10. urza Says:

    Sorry, but there is already an app for that, and rather a good one:

  11. rhaas Says:

    One of my colleagues calls these “Mac turds” when they show up in .zip archives or on shared filesystems. It’s hard to disagree.

  12. snielsen Says:

    Aright, after a sever-melting Christmas Eve and restful Christmas I am going to get to these comments now :)

    @orta, @urza
    Hmm, asepsis looks pretty interesting. Different way of going about the problem. Interposing libc in every launched process is a cool (if slightly more invasive) solution.

    Oh nice! Thanks for making me aware of those. Update coming soon.

    But of course 😉

    Talk to Apple about that (

    @Tom Anderson
    Tried out “DSDontWriteLocalStores”, doesn’t work. Appear like those posts were just speculating that that a related flag like that existed.

    @Mature Mac User
    Yes 😉

    Yea, there a lot of nice cleanup utilities out there that will remove them after they have been laid down. I wanted to stop them at the source.

  13. snielsen Says:


    Just made an update replacing the janky vmmap call with routines that manually lookup the image address.
    Unfortunately nlist() doesn’t appear to exist on 64-bit Darwin :(

  14. Eric Says:

    I didn’t know other people shared my disdain for those files…I call them Mac droppings :)

  15. George Entenman Says:

    Thanks for this article. I didn’t realize that the .DS_Store files were created by the Finder. I rarely use the Finder, preferring PathFinder instead because of its tabbed browsing (and lots of other great features).

    I can find only one page that says that “doesn’t drop or use .DS_Store files” (!-Path-Finder-rocks!).

    But my home directory has 50,735 subfolders and only 685 .DS_Store files. So I guess you’ve found another reason to use PathFinder.

  16. Dan Knight Says:

    The freeware DS_Store Cleaner app can remove the .DS_Store file from an entire drive or a selected folder and its subfolders. Version 1.5 is available in Windows and OS X (pre-10.7) at

    Version 1.6 is for OS X 10.7 Lion

    I’ve been happily using version 1.5 for years.

  17. SeanJA Says:

    @Dan Knight

    Or you could just do this in the terminal (console? cmd prompt? not sure what it is called on a Mac):

    find . -name ‘*.DS_Store’ -type f -delete

    No need for any special software

  18. Tommm Says:

    Is this file related to thumbs_db on Windows?

  19. fjpoblam Says:

    ¡C! for getting rid of .DS_Store (often a time-consuming doltish file during my FTPs, too: I go from local folder to host folder based on last-modified).

    Now, if I could only get rid of *another* annoying MacOS dot file habit: when I delete files from a thumb drive, the file isn’t deleted but renamed with a dot. My Windoze boxes don’t do this. E.g., trash temp.doc and end up with a “hidden” .temp.doc” …Grrr. I’ve run into illusory space shortage more than once…

  20. Dre Says:

    Hi there… How to reverse things back, if I run this app?

  21. snielsen Says:

    @Tommm Some people have drawn comparisons with thumbs_db but they have significant differences. The most important of which is that in Windows you can turn them off :)

    @Dre To reverse things you can simply relaunch the Finder (Command+Option+Escape or whatever your preferred method is). If you installed the Launch Agent then simply un-check the “Launch Agent Installed” box in the app and it will no longer patch the Finder every time you log in. The app doesn’t actually change the any of the Finder files on disk, it changes the copy of the Finder running in-memory after it has launched.

  22. ATSystems Says:

    @ Mature Mac User

    I’m a Windows server admin for a large marketing and media firm who has been forced (by one manager who makes waaaaay more noise than the rest of the managers, who, incidentally, disagreed) to allow OS X into our environment.

    Our fun with .DS_Whore started almost immediately when my scripts to merge directories across different sites etc started to break, because there were duplicate file names in the source and the destination.

    The fun continued when my OS X users, being the creative little darlings they are, started colour coding and messing with their local finder view of a given directory on the server. Then another user would try to modify the finder view to their own taste. Then the first user was on the phone to me asking why their finder view kept changing.

    The fun ended when our CTO realised these machines were arbitrarily writing files to our servers that had nothing on earth to do with our primary role, and banished all OS X machines back off the network. I wont go into other factors here, but .DS_Store was a big one

    Never mind the fact I have had personal external drives riddled with this crap at LAN parties and the like because OS X users were browsing my shares. I don’t know what kind of cluttered mess you have your data arranged into, but I run a tight ship, and the only person who writes to my drives is me. Period. Much less someone on another machine for gods sake!

    Not so harmless in the real world friend.

  23. RedSetter Says:

    @ Mature Mac User

    Much like ATSystems I loathe OSX in a cross platform environment and no I am not just talking from a Windoze point of view.

    Splattering a non-user identifable file in every ficken directory you browse is epically stupid and annoying. Way to go to break most file maintenance. SMBX? yeah use pid.high as a Apple only mid.high in CIFS transfers it not like its a protocol standard or anything like that.

    Macs have their place, at home looking pretty, not connected to a cross-platform network. The sooner .DS_Store dies the better.

  24. Mauro Says:

    It’s like nuclear waste really. In 2130 there will still be people wondering what to do when they find those files. Then in 2400 Apple will achieve the 100% of computers of the World(s) and the DS store will have its revenge! Unfortunately nuclear will still be a problem.

  25. Tim Kimpton Says:

    doesnt work on Mountain Lion

    Could not access task for pid XXX. You probably need to add user to procmod group
    mach_inject failing.. (ipc/send) invalid destination port

  26. Tim Kimpton Says:

  27. Tim Kimpton Says:

  28. James Gibbons Says:

    Thanks for the info on .DS_Store.

    I just spent all the previous day fighting a problem with .DS_Store. I use a QNAP NAS for data storage (Linux box with RAID AFP and SAMBA file share). I also use Retrospect to back up the NAS and move files around from system to system. I normally mount shares using AFP mode.

    For some reason I noticed that it would no longer move files. It also wouldn’t back up all the files. At first I thought it was a permission thing, and did find a numeric group permission on some of the NAS folders that wouldn’t copy. I used CL to force proper permissions, user and group but things still would not copy. Retrospect would give errors like this:

    While scanning volume Recordings,
    Folder /Volumes/Recordings-3/HDTracks Music/Pat Metheny/…ic/Pat Metheny/…,
    Scanning incomplete, error 24 ( unknown)

    Looking further into this mess I found some files named “:2eDS_Store” instead of “.DS_Store” (:2e appears to be an escape for the period character). I have no idea what caused this, but the folders with this corrupted name would not copy. I could look into the folders with the Finder, but Retrospect would not copy them. I dropped into a command line on the Mac and used sudo to start a new root session of bash and went into the directory that Retrospect had mounted. Sure enough, using “ls -alR” on the hidden directory would give errors but would still show the files. Somehow, Retrospect was becoming confused. At least now I know how to fix it.

    This site has some discussion on this and a script to remove the files:

  29. astimony Says:

    Thanks for the great and in depth article an the utility. I can’t believe this .DS_Store madness continues?

    What is the explanation for that, why is it acceptable at all?

    Imagine if when Google chrome came out it:

    – stored a file in every directory you visit on devices attached to it
    – uploaded a file to every website you visit
    – stored those files with a name that is known to make it unlisted in directory listings
    – stored information about your personal desktop and what you were doing at the time

    And THEN it:

    – writes that file in every directory you visited on any device attached to your computer
    – uploads that file every time you request a page from any website

    Imagining it like that: if Google chrome had done that when it came out nobody would be using google chrome right now, can you imagine? The outcry would be tremendous.

    The same for Microsoft Windows, I’m just using some examples for comparison, if Windows came out with a version of Explorer that did that, we would all be hearing about it on the 5 o’clock news, security experts would get some commissions for talking head time on television …

    Speaking of security experts – what the hell?

    There must be some weird explanation for this: the weerdest thing being that this practice continues and I am feeling as I write this like I have to argue for this, how is this not obvious and BLARING like a Mac truck smashing through your living room window and impacting with your face? It is SO BIZARRE, it is NOt NORMAL that this kind of thing happens and everybody is __so__ laissez faire about it, it is an OBVIOUS and GIGIANTIC ongoing security vulnerability for EVERY MAC USER and nobody is doing anything about it, we have rely on the excellent work of someone like yourself to go in and HACK system level code to stop our computers from
    this is insane!

    ~*~ astimon

  30. Howard Says:

    Thanks for the info – just ran into an issue with .ds_store when trying to copy a non-trivial sized directory hierarchy to my bitcasa volume. I had noticed that I got an unspecified error when copying the hierarchy through finder (though I suspect that could be related to multiple things), so I ran cp from terminal and got an I/O error for the .ds_store file. I’m still trying to determine more details around why I got the error, but regardless, if there’s a way to not have this metadata file hanging around (particularly since I live and work in a heterogenous computing environment), I would certainly prefer it.

  31. Jorge Says:

    We have a huge Windows Files Share environment (50 TB). While looking for an archiving solution, we found a product called Archive Connect, so the mac clients can properly see and use the stubs left behind for the archived files. The only caveat is that macs that do not have this software installed, can re-migrate archived files back by simply opening a folder. Our solution was to create a file filter in the windows servers that would not allow the creation of .DS_Store files. This is course, also had the added benefit of no longer having the thousands and thousands of these files in our file servers.

  32. Cat Says:

    Hi. Thanks so much for this app, though I have a question.

    When I open your app, I get an error message which says “Need /usr/bin/nm. Install the Developer Tools.”
    I have no idea what that means.
    Maybe you can help.

    Thanks again.

    As far as my nightmare with DS Store files….
    .DS_Store is blocking me from copying files and folders to other folders both on my external and internal hd, despite the fact they are invisible files.
    I get an error message which says something like “Cannot copy files to new location. A .DS_Store file already exists”.

  33. snielsen Says:

    @Cat That message is referring the Apple Developer Tools that are freely available from (account signup required). Unfortunately the Death to .DS_Store app currently has an external dependency on a program called “nm” which you can get by installing Apple’s Developer Tools. One of these days I want to find some time to update the app and codebase for Mountain Lion and Mavericks and see if I can eliminate the external dependencies as well.

    Sorry to hear about your .DS_Store problems. Hopefully one of these days Apple will finally get rid of it and implement Finder metadata the correct way.

  34. tim kimpton Says:

    How about using package maker, iceberg or jamfs composer to maker an installer that will include nm?

  35. snielsen Says:

    Ideally, I would like to just pull in the functionality that I use nm for right into the app itself. Distributing a binary nm might have licensing or other issues but it may end up being fine to do it that way as well.

  36. chimi Says:

    Seems to not work on OSX Mavericks :(
    Feel like taking another look at this?

    These stupid files are making me consider switching back to Windows…

  37. snielsen Says:

    @chimi Funny you should mention Mavericks… I just got new hardware recently and made the jump from 10.6 to 10.9 for my daily driver. Thus, fixing up DeathToDSStore has become a priority for me 😉 Last night I got it to work on Mavericks and I will probably make the source commits to Github tomorrow along with a new binary after I do some more testing.

  38. snielsen Says:

    Ok, I have committed the update and the download link now points to DeathToDSStore 1.0.2 which will work on 64-bit Snow Leopard, Lion, Mountain Lion and Mavericks.

    Unfortunately, the launch agent functionality on Mountain Lion and forward is somewhat intrusive. Now every time you login you will be prompted to give permission for the Finder to get patched (it is worded in a weird way: “Developer Tools Access is trying to take control of another process. Type your password to allow this.”). This is a side-effect of the Gatekeeper policies which went into effect in 10.8.

  39. Kai-Uwe Says:

    First of all: BIG THANKS for this tool and the update for Mavericks!
    Regarding the permission prompt for the launch agent, there is a rather simple solution to this.
    Please set the sticky bit for the user root instead of for the group procmod on the injector binary, i.e.
    “-rwsr-xr-x 1 root procmod 42112 8 Nov 22:57:11 2013 injector”
    and the prompt will no longer occur.

  40. snielsen Says:

    @Kai-Uwe Oh awesome! Thanks so much for the tip :) Works great! I added the change, bumped the version to 1.0.3, committed the source and updated the download link. Anyone that downloaded and installed 1.0.2 should delete the copy of the app that gets installed at /Library/Application Support/Aoren/ and /Library/LaunchAgents/com.aoren.DeathToDSStore.plist and then have 1.0.3 install the launch agent again.

  41. Nils Says:

    Asepsis v1.4 has a annoying “feature” that is looks for updates a every six hour or so. I have blocked that program from connecting to what ever server and it now pop up window saying it cant connect to the server. Pure crap “feature”.

    Do v1.0.3 need to be run every time the machine start? It says so with the -silent thing but to make a script run it at boot as root needs root password typed in every boot. Right? The best would be run it one time, type root password and it gets installed and have disabled the “feature” in Mac OS X that creates the trash .DS_Store files all over the drives.

    I’m not a script guy but there must be a script of some sort to start in the background so no annoying windows pop ups. Just so the programs does its thing?

  42. snielsen Says:

    @Nils As of the current version if you enable the Launch Agent it should automatically run silently every time a user logs in. Let me know if you see different behavior. Be aware though that if you quit or restart the Finder process after logging in, that it will relaunch unpatched and will create .DS_Store files. The Death To .DS_Store Launch Agent only kicks off upon user login and not on Finder process launch. I have observed that Dropbox actively detects when the Finder process runs and will aggressively patch it every time it relaunches. That would be nice functionality to incorporate down the road or if anybody wants to work on it I would welcome a pull request.

  43. SaxDaddy Says:

    Thank you for writing/updating this utility. You don’t really notice the impact of DS_Store until you go cross-platform. Just like I constantly see “Thumbs.db” from Windows boxes. FYI, I had almost 350MB of .DS_Store files on my 250GB drive. So it’s a gallon of water in the ocean but it still simply didn’t need to be there.

    @SeanJA: Quick observation that your command (“find . -name ‘*.DS_Store’ -type f -delete”) didn’t work for me on 10.9.2 until I changed it to find . -name “\.DS_Store” -type f -delete. But thanks b/c this was a good way to cleanup the files after starting the utility.

  44. Shan Says:

    Simply you can put following command into your .profile file or .bashrc

    find ~/ -name .DS_Store -delete

    when you open terminal window automatically it will remove all .DS_Store files from your computer. So you do not need to worry about deleting it.

  45. Kai-Uwe Says:

    Unfortunately Death to .DS_Store is broken under OS X vYosemite. After some research I found this to be a problem with mach inject. There is a fix for this already. Is it possible to have a v1.5 recompiled with the new mach inject code (please see
    Would be very happy about this, of course!
    Thanks for looking into it.
    Brgds Kai-Uwe

  46. Kai-Uwe Says:

    Please discard my last post. I have found v1.0.4 in the meantime and it is compatible with OS X Yosemite already. Thanks for the really fast update – and I still like Death To DS_Store very much!
    Brgds Kai-Uwe

  47. snielsen Says:

    @Kai-Uwe Yea, I saw that Yosemite issue and patched it real quick in 1.0.4. There is still a race condition between the time that the Finder launches and when it is patched by the launch agent but at least it doesn’t crash the Yosemite Finder anymore :)

  48. Sjors Says:

    So, how do we disable or uninstall the launch agent? I also want to try out redirection of ds store files. And what’s the binary name to operate the command line version?

  49. snielsen Says:

    @Sjors, to uninstall the launch agent you simply open the app and uncheck the “Launch Agent Installed” checkbox.

    The app’s binary itself (DeathToDSStore) serves as the CLI binary as well. Just pass the “-silent” parameter and it will only run in CLI mode.

  50. Rick Says:

    Any chance DeathToDSStore could be made to run as a menu-bar-only app, i.e. no icon in the task list when Cmd-Tabbing?

  51. snielsen Says:

    @Rick, probably not. The app is not meant to be kept open after you use it to patch the Finder. In fact, ideally you just use it to enable the launch agent and never run it again!

  52. a Says:

    Thank you so much, I’ll post again if there are issues.. I’m on Yosemite 10.10.3 using, and for cross-network data management. Since the first two apps I’m using (plus the DeathToDSStore app now) integrate tightly with Finder, it will be interesting to see if they all play nicely. Do you think there would be any issues running Asepsis and DeathToDSStore together? How would they interact? Everything is currently syncing great, except for the all the Mac turds lying around!

    I’ve also reported the bug 😉

  53. snielsen Says:

    @a There shouldn’t be any problem running both at the same time. Asepsis patches libc and redirects file interaction to a centralized .DS_Store holding pen. DeathToDSStore suppresses their creation by

    In practice, DeathToDSStore works well except since 10.9 there is a significant race condition involving when is launched and when the DeathToDSStore launch agent is kicked off. This means that when you log in, the Finder has the opportunity to write a .DS_Store file for every currently open Finder window before the launch agent (which patches the Finder and suppresses .DS_Store creation) gets run. I haven’t had any time to investigate any sort of mitigation for this yet but want to get around to it sometime.

  54. a Says:

    There doesn’t seem to be a problem with running ExpanDrive, TotalFinder and DeathToDSStore and I’ve eliminated Mac turds from my life, ahh fresh air! How much would it cost to update DeathToDSStore?

  55. snielsen Says:

    @a DeathToDSStore is a hobby for me and so it is more of a time issue than a money issue. Ideally Apple will finally surprise us in 10.11 and fix their most glaring design bug :)

  56. a Says:

    So basically DeathToDSStore makes Asepsis unnecessary because it’s blocking the creation before Asepsis pens the files? I’ve noticed that Asepsis sometimes doesn’t work as expected or is not updated frequently. Also, the issue of the race condition is not a big deal since I never restart, and when I do I’m happy to wait until everything loads. Worst case, I’ll have to remove a DSStore on the Desktop (my default folder when TotalFinder opens). Does the race condition pose any stability or data corruption issues? Have you considered making a donation page or selling this app to fund maintenance?

  57. a Says:

    I posted before I noticed your reply, thanks for the feedback. I’m subscribed and look forward to future updates as your time permits.

  58. Evgeni Says:

    Should this app be installed separately for each user on my Mac?

  59. snielsen Says:

    @Evgeni If you install the launch agent then it will activate for every user on your Mac when they log in so there is no need to run the app or initiate the install procedure for your other users.

  60. Tricky Says:

    I can tell this even crazier. I also find a lot of ._ files in my directories. Like if I have a file named myimage.png then I can be sure I’ll soon have a ._myimage.png, and to make it worse the .DS_Store files often also fall through this making me stuck up with a .DS_Store file and a ._.DS_Store file.
    I recently fixed up a small app to remove all .DS_Store plus all “._” files, and I effectively won 15 GB in the process. Not to mention that I recently had to clean up my GitHub repositories as whatever I do to ignore them, a few of them always manage to sneak in.
    When I was Mac user for a short time I did find these files when I took my memory stick to work, and I always wondered what they were for and how they got there (as on work I had to use Windows), I found out later it was my Mac doing it. And I really wonder how much time I’m going to need to clean all servers hosting a website of mine because of some .DS_Store files.
    I’ve seen this recommended on several sites, so I hope this is the solution. I like Mac, it’s the only reliable operating system I’ve ever come across, but these .DS_Store files are really a cancer in this otherwise great product.

  61. Josh Says:

    As of 10.11 Beta (15A234d) not only are .DS_Store files still created, but Asepsis is blocked by System Integrity Protection.

    On Github, darwin said:

    “AFAIK Asepsis under El Capitan with System Integrity Protection enabled is not possible.

    I’m going to stop developing Asepsis and supporting it under El Capitan.” ( )

    After testing DeathToDSStore in 10.11 beta via cask, the creation of .DS_Store files seems to be halted. Does this mean it’s now our only hope?

    And as a follow up: What’s in these files anyway? Is there anything besides the fact that I like viewing that particular folder’s contents as list view, and may have added an icon to a file?
    These both seem like really trivial reasons to enforce .DS_Store files, even against user and OPSEC wishes. Someone, please tell us there’s more.

  62. snielsen Says:

    @Josh I haven’t had time to test Death To .DS_Store on El Capitan yet but I would actually be surprised if the mechanism that we use to inject code into the Finder is still allowed under the new security model. I will try to find some time this week to do some tests. Sometimes the Finder is funny about when it flushes the files to disk and so you might want to let it sit for a bit to see if it actually kicked in. Also, on 10.9/10.10 at least there is a race condition that allows the Finder to write the files to any open window before the patch kicks in during the login process so you might see a couple written here and there every time you reboot.

    If El Capitan is indeed the end of Death To .DS_Store, then I think it is time to starting filling radars, requesting they get dup’d to radar://17348033 and harassing Tim Cook’s twitter account :)

    To answer your question, they are just Finder metadata. Label info, icon positions, view defaults, icon associations etc. Moderately useful, but not vital information that clearly should be stored somewhere other than the filesystem.

  63. a Says:

    I reported DS_Store to in April 2015 and got an email in August 2015. They closed my bug report saying it was a duplicate issue for bug 3479171, so I guess it’s already in the system. Did one of you file that :)

  64. Wowfunhappy Says:

    For El Capitan, why not just turn off System Integrity Protection? The extra security doesn’t seem all that necessary for a power user who knows what he/she is doing.

    Will this tool work for ._ files as well? Those bother me a lot more than .DS_Store, because there’s a heck of a lot more of them!

  65. Blue Says:

    I always just use: because it runs in my menubar and cleans these files automatically. I keep movies on a removable hard drive and it annoys me to see the mac system files when I plug the drive into my tv and browse.

  66. Roger Says:

    .DS_Store seems to be back in El Capitan and possibly worse than Yosemite. Any ideas?

  67. snielsen Says:

    Turning off System Integrity Protection is an option which will allow Death To .DS_Store and Asepsis to work again. Your system won’t be any less secure than Yosemite. If you are confident that your system’s outer defenses are good enough to keep any bad actors out, then SIP won’t make any security difference. It only mitigates the damage that something can do once it is already in your system and has somehow gotten privilege escalation.

    That said, there has never been a better time to file a radar about this issue at :)

  68. Mike Kormendy Says:

    I’m not exactly sure what to put in the bug report that would get any sort of attention, or at least address the issue correctly. Should I say that SIP is screwing things up? Should I say that SIP needs to be augmented? Should I say that we need a native authorized option to turn off .DS_store files in the system settings?

    What do you think would work best?

  69. snielsen Says:

    @Mike Normandy The best thing to write is that Finder metadata should not be stored in the filesystem inside .DS_Store files because the cons of doing so far outweigh the pros. You can also simply ask that your bug be duplicated to mine (radar://17348033) and not write anything else. Bug duplication counts do actually matter within Apple when weighing priority.

  70. whoknows Says:

    I wish Windows ignored dotfiles… grrrrrrrrrr

Leave a Reply

Entries (RSS) and Comments (RSS).