I was hoping that with macos 11 we would see the deprecation of .DS_Store. I'm not running the beta so perhaps it is, but what has surprised me is its sustained longevity. What are the technical reasons for keeping .DS_Store? It is essentially a application-specific (i.e. Mac Finder) solution that pollutes the data store.<p>Off the top of my head I can think of a number of other solutions to store directory metadata: a Finder-specific database mapping values to directory paths, resource forks (ala OS 9), etc.
I'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've seen? People do `git add <i>` and then I find that directory in the repo. Why does git not automatically ignore that?! It'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't HFS. The hell, Apple?!
Personally I hate .DS_Store and they must be deleted. BUT on the other hand I am finishing "a proper missing, a dream File Manager" for Mac OS and thinking about features that would require to store some meta data. Where should I store them? If it's in the folder in form of some ".meta-data" 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/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 ".meta-data" 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 "my file manger of a dream" 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 ...
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'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't because it presumably stays on your machine, and going back to resource forks wouldn't because the earlier OS releases wouldn't know about the existence of them.
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://krashan.ppa.pl/articles/amigaicons/" rel="nofollow">http://krashan.ppa.pl/articles/amigaicons/</a>). But it didn't 'pollute' the filesystem, and was far more manageable.<p>Haiku does things differently, and elegantly: <a href="https://medium.com/@probonopd/my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6" rel="nofollow">https://medium.com/@probonopd/my-sixth-day-with-haiku-under-...</a>)
Well it'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's a brief and somewhat interesting explanation for why it exists, from Arno, the tech lead at the time (2006):
<a href="https://www.arno.org/on-the-origins-of-ds-store" rel="nofollow">https://www.arno.org/on-the-origins-of-ds-store</a>
You could give <a href="https://asepsis.binaryage.com" rel="nofollow">https://asepsis.binaryage.com</a> a shot—it'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'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.
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.