Ask HN: What are the technical justifications for keeping .DS_Store?
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.
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.
93 comments
[ 3.3 ms ] story [ 652 ms ] threadYou can tell the OS not to create them on network mounted drives:
And nitpicking, that wouldn’t be “ala OS 9”. That OS had a desktop database on each volume.
- external drives
- non hfs/apfs drives
- everywhere
99% of the reason it exists is because the OS generated thumbnails. I see these in, for example, zips, that do not have images in them, and have that file.
You know what I've seen? People do `git add ` and then I find that directory in the repo. Why does git not automatically ignore that?! It's never the right option.
Anything* that pollutes directories should be absolutely verboten, its never what the user wants.
Edit: The worst part is, it makes them on network shares, and on filesystems that aren't HFS. The hell, Apple?!
Why doesn't Git automatically ignore desktop.ini? .desktop? __pycache__? In my experience, people end up creating bespoke .gitignore files for each project and sometimes shared online, or systemwide. I don't know if Git should make it global.
I would definitely vote for a way to incorporate sane .gitignore settings per-OS or per-language, but still make it opt-in.
it fails in many teams, they do not care or a junior dev does not know. Many folks don't setup proper dotenv especially designers. Unless added to the project .gitignore file it is going to be added to the project sooner or later.
Getting a team of designers, content writers, marketing folks to use anything beyond their daily tools over a period of time is hard.
I had the marketing team run a git managed, asset pipeline ,CI deployed Hugo static site via a CDN for three years, with great performance and high availability for three years, now we run hubspot.
Once the initial team moved on, It was next to impossible to hire people willing to work on that stack , typically new guys will know Wordpress or hubspot etc, my TAs had frustrating time sourcing, I finally had to give up .
Administrative Config in yaml/JSON files in a git repo sounded a nice idea , git gave version history rollback, audit log, branch/env, CI driven deployment all sounded great.
Same problem typical operation folks are not used to this , they want a nice UI , and keep clicking and rather than do a grep/Sed replace in a jiffy.
People just like different ways of working , it is hard for me to think graphically like a designer , I can understand that it can be hard for someone to think in text , it is better we give them tools that are comfortable with and fight other battles
If your team doesn’t care, by definition they don’t see it as a problem, so it only doesn’t work in the sense that they have decided hat they don’t need a solution.
If your team cares but your junior devs don't know, you need to work on your standard practices documentation and onboarding procedures. “Use this default baseline .gitignore" is not a very arduous level of standardization that is hard to instill in new juniors.
Whenever I switch computers, one of the very first things I do is copy over my bindings in CAD so that I don't have to relearn / figure them out again. I don't see why it'd be so hard to just store your own somewhere, and use it over and over again.
- Different programming languages have different files to ignore. I hop between many languages.
- It might be a bit weird for multiple repos to have the same root commits. Not sure.
gi macos node > .gitignore
They also have to redo everytime they reset their system. Since Mac will not show the folder in Finder they won’t even notice when they don’t do it , it is annoying for the rest of us.
Git should not be limited to few folks who understand version control, there is a lot value for people who can just it linearly for collaborative history tracking
Like the MS of the past, Apple does not care about compatibility unless they forced to.
QuickLook thumbnails actually go in a different cache as they are dynamically generated. .DS_Store files contain things like folder layout information.
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.
It doesn’t really bother me as it is, but it’s on the less-than-perfect list.
Today, macOS uses extended attributes (which were already mentioned) which stashes things like where you downloaded it from, if it's quarantine (first launch warnings), if it's a screen shot, etc. Funny enough, when you place something in the Trash it stores the former location (so you can put it back) in DS_Store.
Generally, metadata is either stripped or just plain gets messed up when switching OSes depending on the partition type and tools used to transfer.
That’s incorrect. File type and creator were stored in the file system, not inside files.
“I believe icons were stored there”
Icons typically were stored in resource forks, but not in the way I think you imply. Applications defined mappings from (type,creator) to icon in their resource forks (which also stored lots of other stuff, including application code). The Finder merged all the mappings needed in the desktop database (each disk had one, stored at the top level of the disk)
The icons couldn’t be read from each file because opening each file would slow down the Finder (it was slow enough to start with) and, I guess, it would take way too much disk space (a single 32×32 black and white icon with mask is a whopping 256 bytes. Overhead probably made that a kilobyte on disk. That adds up on a 400kB disk)
Haiku does things differently, and elegantly: https://medium.com/@probonopd/my-sixth-day-with-haiku-under-...)
If a file did not have corresponding .info file it wouldn't show up in the UI (unless you selected option to show all files).
I miss Amiga :)
Synology pollutes my directory with @eaStore and @syno crap.
WHY?
I have Mac, Windows, and a Synology. I also sync this to Google Drive (using rclone) as a backup. My network shares, and Google Drive, are polluted with crap and I don't know how to fix it :(
https://www.reddit.com/r/kde/comments/avmsdt/dolphin_is_grea...
Doesn’t mean it’s right... but this is my anecdotal experience.
And probably better to limit this to "~" rather than "/".
I think the data would be just fine stored as metadata on the directory or a centralized database that wasn't persistent between computers and the disruption would be minimal. Spotlight comments, which Finder reads from DS_Store, is also written to extended attributes. It just isn't read from there. Trash stores each file's previous folder in DS_Store, which could be problematic on a different computer (and nobody would expect that to persist).
In the same view options configuration window, have a checkbox option to make the configuration portable along with the files, in which case write it out to .DS_Store or a similar file, to be used as a local override à la .htaccess
Explaining this option succinctly may be a challenge but not impossible. Maybe "Save view options with folder" with a hover tooltip explaining that this would enable the view options to remain the same across user accounts and computers.
> Maybe "Save view options with folder"
I like it, it's not only 'view options' though, as you understand. Many '.DS_Store' files are already there for many folders and I have to deal with them while compare sizes etc. Right now they are copied because I do not think FM should be invasive in your data as a general principle. But some option along the lines of "Copy meta data too" I think is reasonable way to deal with them.
As mentioned by other comments, store it in a centralised cache/config/whatever for your application.
Can I sign up to be notified when it's released? :)
That probably is doable on modern local hardware, but on network disks, it might still be slow.
Make that an IMHO not unreasonably large 500 photos and your local disk might be slow, too.
Add a virus scanner, and 100 photos might already be annoyingly slow.
⇒ I would try to find a way to store away the checksum somewhere in the file (say in an extended attribute, as a (modification timestamp, checksum) pair)
If you do that, you only have to read the whole image the first time. Once you created the thumbnails, you only need to read them, and they’re a lot smaller, and can be put in a single file.
The proposed approach reads a significant part of each file to determine whether the cached thumbnail is still current. That doesn’t give a huge improvement over not caching thumbnails at all (factor of 5 in bytes read/network traffic, as a rough guess, likely less in disk seeks)
FM that takes a lot of memory or FM that use computation resources when required only. I tend to think that in general expectation from FM is to be very small in memory demands and take valuable computational resources only if it is absolutely necessary.
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.
This isn’t only a mac thing either. Other OS create their own variations of debris.
A quick google search finds several blog posts with commands to run.
Apple usually prioritizes bugs by duplicate count.