These are arguably one of the smaller annoyances about apple when not using one myself (so, always) and they have become less relevant over the last years as sharing things via USB has become less common and I don't use dropbox or such with shared folders anymore. People who use git don't tend to check these in, when working with me at least, I make sure of that.<p>But it's a pretty darn good symbol for how Apple doesn't give a flying fuck about anyone's time/nerves, just dumping these on everyone without asking and letting us deal with their laziness.<p>Plus, Apple <i>users</i> then typically just rolled their eyes when I point out to them that I've now got all these files on my USB drive, thanks for nothing Apple.
"Why do you even care?"
Yeah, why do I? There's just no reason I should have to sort through these to keep them out of my systems, yet I don't want them there so no I have to, thanks apple... (this was before I got good on the terminal so it was actually quite annoying)<p>Bottom line: this still gets my blood boiling. Fuck apple, they're the new Microsoft in every way.
Some past related threads:<p><i>.DS_Store</i> - <a href="https://news.ycombinator.com/item?id=26435783" rel="nofollow">https://news.ycombinator.com/item?id=26435783</a> - March 2021 (30 comments)<p><i>Ask HN: What are the technical justifications for keeping .DS_Store?</i> - <a href="https://news.ycombinator.com/item?id=23648165" rel="nofollow">https://news.ycombinator.com/item?id=23648165</a> - June 2020 (91 comments)<p><i>.DS_Store</i> - <a href="https://news.ycombinator.com/item?id=20340151" rel="nofollow">https://news.ycombinator.com/item?id=20340151</a> - July 2019 (21 comments)<p><i>Don't commit your .DS_Store files</i> - <a href="https://news.ycombinator.com/item?id=17134324" rel="nofollow">https://news.ycombinator.com/item?id=17134324</a> - May 2018 (2 comments)<p><i>.DS_Store files always hidden from Finder in macOS Sierra Beta</i> - <a href="https://news.ycombinator.com/item?id=12056993" rel="nofollow">https://news.ycombinator.com/item?id=12056993</a> - July 2016 (11 comments)<p><i>.DS_Store for non-mac users</i> - <a href="https://news.ycombinator.com/item?id=5733022" rel="nofollow">https://news.ycombinator.com/item?id=5733022</a> - May 2013 (15 comments)<p><i>Death to .DS_Store</i> - <a href="https://news.ycombinator.com/item?id=3390509" rel="nofollow">https://news.ycombinator.com/item?id=3390509</a> - Dec 2011 (122 comments)
Since Windows and MacOS don't seem interested in having mutually supported advanced filesystems, it would be nice if we just standardized on a flat file structure to implement portable features.<p>fat32 is very portable but has a 4GB limit and lacks entered attributes. exfat probably supports everything but until very recent open source drivers it lacked cross platform compatibility.<p>Plus too many devices are going to be limited to fat32 so we might as well just use that as a common denominator.<p>It would be nice if a DS_Store system could be used to associate split files (e.g. $NAME.1 $NAME.2, etc.) as a word around for the 4GB limit. User permission attributes and other extended attributes could be stored as well.<p>What's interesting is that Fat32 had this feature implemented on OS/2 and Win NT via files with the "␠EA.␠SF" suffix. Unfortunately looks like it was dropped in Windows 2000.
So, why aren't these just stored in a db or some other directory of the OS? Instead of littering the userspace, and no fs-ext required. Also it sounds like these should be per-user-and-dir instead of just per-directory.
Ah, .DS_Store. As a Windows user forced to endure this offensive clutter I curse the fucking bastard that came up with that.<p>No love either for the twerp who invented desktop.ini or caused thumbs.db to seemingly keep coming back after I repeatedly turn off that feature.<p>If you're interested in such voodoo arts check out NTFS Alternate File Streams too (which while the bane of many at least have the decency not to spread to filesystems that don't support them).
This wasn't much of an explainer, it didn't even cover all the things that .DS_Store is capable of managing. The wiki does a better job of covering the topic.<p>It's also not something to get upset about - if .DS_Store or Apple double files (or for that matter Desktop.ini / thumbs.db) are a surprise then it's time to hang up one's coat, they're trivially revealed in the terminal and so predictable and easy to deal with that complaining about them is akin to holding up a dunce sign.<p>If one has purchased hardware/software that can't cope with them: get a refund, this shit is entry level basic.
Finally I understand the perspective of mac users in this problem. I had assumed that showing hidden files and manually cleaning up the zip archive would be a "simple no-brainer solution".<p>I just can't comprehend the reasoning of hiding .DS_Store <i>beyond</i> the reach of viewing hidden files. This is user-hostile. Why don't the native zipping tools automatically ignore these files when creating an archive?
TLDR: .DS_Store files are Desktop Services Stores, containing that folder’s custom attributes, things like icon positions, and in more recent versions of macOS custom settings for the display of file metadata. Among the most important for some users are Finder or Spotlight Comments, which are normally displayed in the Comments section of the Get Info dialog for a file.
From my knowledge .DS_Store is something everyone hates and no one actually benefits from, I personally hate it with passion and there's several times I wanted to work at Apple to remove it. Is there a reason why macOS still keeps it, do they actually think it's a good idea, or they don't like to listen to users, or they didn't get to do it yet?
There is an awesome Atom plugin called "ds-store-delete" which allows me to use ctrl-alt-x or click a bright red button in the bottom left corner to delete all .DS_Store files in a workspace.<p><a href="https://github.com/pedroparra/ds-store-delete" rel="nofollow">https://github.com/pedroparra/ds-store-delete</a>
I just realized that once my girlfriend (against all my advice...) gets her new Mac, these fuckers will show up on our NFS server, huh?<p>Does anyone know how to prevent that from happening? It's a non-auth NFS, so anyone on the network is supposed to see and use it. So a server-side solution would be preferable, but client-side will do in a pinch.
It makes sense to hide these files from many macOS users who don't care about them. For developers (who should be able to work with a Terminal) there's no need to resort to any magic or special command to make them visible! They are normal hidden files. A simple `ls -a` will list them too. You also have to put them in .gitignore as you put desktop.ini and other window managers' metadata files.<p>I wish the author explained in more technical detail or clearer how and where these files cause problems (not doubting that it does). In that case, it would have made a really useful article.
More than the DS_Store files what fascinates me is that when you delete something on a USB stick it doesn't go away, making the life of the stick limited to one write. This, unless you format it, but how many regular users understand it?
The champions in usability...