Ask HN: What are the technical justifications for keeping .DS_Store?

I&#x27;m going to be honest: it should be deleted when seen, and OSX should have never begun this.<p>99% of the reason it exists is because the OS generated thumbnails. I see these in, for example, zips, that do <i>not</i> have images in them, and have that file.<p>You know what I&#x27;ve seen? People do `git add <i>` and then I find that directory in the repo. Why does git not automatically ignore that?! It&#x27;s never the right option.<p></i>Anything* that pollutes directories should be absolutely verboten, its never what the user wants.<p>Edit: The worst part is, it makes them on network shares, and on filesystems that aren&#x27;t HFS. The hell, Apple?!

.DS_Store is like the filesystem equivalent of &#x27;Sent from an iPhone&#x27; --- it lets everyone know you used a Mac.

Personally I hate .DS_Store and they must be deleted. BUT on the other hand I am finishing &quot;a proper missing, a dream File Manager&quot; for Mac OS and thinking about features that would require to store some meta data. Where should I store them? If it&#x27;s in the folder in form of some &quot;.meta-data&quot; then it would be copied when you copy data and be available there in another machine, or I can create it inside the OS somewhere, but then how to transfer it to usb drive for instance? I do not like idea of data to be polluted with some extra .something, I really hate the idea, but how to deal with it to keep it manageable? I can make some indexes&#x2F;pre-calculated sizes in the root of the drive, if user chooses to have those, BUT then if we speak about shared network folder, it then may very well appear in some folder after all because it was mounted as a drive, so the only solution would be to put it in ... well the same &quot;.meta-data&quot; just like .DS_Store that I hate. Then only thing to do about it is to give a choice to user when he copy something, to avoid copying those too. Right now I am using constantly &quot;my file manger of a dream&quot; and actually almost forgot about .DS_Store disaster, because honestly I have no need for poor Finder anymore, and thus .DS_Store is not created at all, but should I add something like this for extra features which would -really- require them? What do you think? Putting yourself in the shoes of someone designing File Manger you kind of see where .DS_Store comes from. Still, hate it :) Really thinking what to do for some time now ...

.DS_Store is the new Thumbs.db. Our descendants will keep finding them in the backups and scratch their heads.

MacOS does have the ability to store any arbitrary metadata in extended attributes, which would indeed seem to be a far better solution here.<p>It doesn’t really bother me as it is, but it’s on the less-than-perfect list.

DS_Store is stored alongside the files, which means it&#x27;s portable with them, e.g. when you put files on a USB stick and then plug it into a machine running an earlier version of macOS 10.<p>None of your solutions preserve that backwards compatibility -- the database wouldn&#x27;t because it presumably stays on your machine, and going back to resource forks wouldn&#x27;t because the earlier OS releases wouldn&#x27;t know about the existence of them.

Windows has thumbs.db, but seems to do a reasonably good job not copying it into stupid places.

I destroy them with reckless abandon and, knock on wood, haven’t had an issue in 15-ish years of driving OS X.<p>Doesn’t mean it’s right... but this is my anecdotal experience.

The Amiga had an equivalent: every visible icon was accompanied by a small metadata file appended with .info (More information here: <a href="http:&#x2F;&#x2F;krashan.ppa.pl&#x2F;articles&#x2F;amigaicons&#x2F;" rel="nofollow">http:&#x2F;&#x2F;krashan.ppa.pl&#x2F;articles&#x2F;amigaicons&#x2F;</a>). But it didn&#x27;t &#x27;pollute&#x27; the filesystem, and was far more manageable.<p>Haiku does things differently, and elegantly: <a href="https:&#x2F;&#x2F;medium.com&#x2F;@probonopd&#x2F;my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@probonopd&#x2F;my-sixth-day-with-haiku-under-...</a>)

Could always add this to your crontab<p><pre><code> *&#x2F;20 * * * * root find &#x2F; -name &quot;.DS_Store&quot; -depth -exec rm {} \;</code></pre>

Well it&#x27;s pretty simple. The Finder allows you to customize a folder (icon positions, background picture) and that data has to be stored somewhere.<p>You can tell the OS not to create them on network mounted drives:<p><pre><code> defaults write com.apple.desktopservices DSDontWriteNetworkStores true</code></pre>

Here&#x27;s a brief and somewhat interesting explanation for why it exists, from Arno, the tech lead at the time (2006): <a href="https:&#x2F;&#x2F;www.arno.org&#x2F;on-the-origins-of-ds-store" rel="nofollow">https:&#x2F;&#x2F;www.arno.org&#x2F;on-the-origins-of-ds-store</a>

You could give <a href="https:&#x2F;&#x2F;asepsis.binaryage.com" rel="nofollow">https:&#x2F;&#x2F;asepsis.binaryage.com</a> a shot—it&#x27;s unmaintained and unsupported since El Cap, but it apparently still worked on El Cap if you turned SIP off. Maybe it still works.

Well, I could go on a rant around their purpose and some of us would ultimately decide these files <i>like so many others</i> are actually just debris.<p>Instead I will say we can have a set of critters that cull them in various interesting ways. Critters that watch filesystems for these files and remove them if they still exist an hour after creation. Or remove them all on a schedule. Or block list them via .gitignore and similar. Sync scripts that have block lists for files and folders that match names. The solutions are endless.<p>This isn’t only a mac thing either. Other OS create their own variations of debris.

It used to bother me, but not anymore. I always put it in my .gitignore files, and otherwise ignore it. You could alias “ls” to not show it.

It&#x27;s an approach that works reasonably well in the Unix world of OS X and platform agnostic servers. It plays nicely with non-Apple filesystems including network shares using non-Apple protocols. It also makes it fairly trivial to keep the metadata with the files when moving things around with generic Unix command line and archiving utilities.

If you’re enough of a power user to notice, then you should be able to figure out how to disable them.<p>A quick google search finds several blog posts with commands to run.

Did anyone create a bug report for Apple I can duplicate?<p>Apple usually prioritizes bugs by duplicate count.

These folders are really useful to identify immediately the clueless developers who put them inside zip files or commit them to git repos. They are a fast way to know that you do not need to take whatever these people do too seriously. I hope macos continues creating these stupid files forever.