17 ms·
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.
- whalesalad 6y agoI destroy them with reckless abandon and, knock on wood, haven’t had an issue in 15-ish years of driving OS X. Doesn’t mean it’s right... but this is my anecdotal experience.
- Gaelan 6y agoYou could give https://asepsis.binaryage.com https://asepsis.binaryage.com 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.
- mark_l_watson 6y agoIt 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.
- smnrchrds 6y agoI don't use macOS and even I cannot get away from them. Someone zips a folder and send it to me and when I unzip it, there would be a .DS_Store inside.
- LeoPanthera 6y agoWell it's pretty simple. The Finder allows you to customize a folder (icon positions, background picture) and that data has to be stored somewhere. You can tell the OS not to create them on network mounted drives: defaults write com.apple.desktopservices DSDontWriteNetworkStores true
- anoncareer0212 6y ago> 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.
- Someone 6y agoIf you go for “resource forks”, you still would need a file. And nitpicking, that wouldn’t be “ala OS 9”. That OS had a desktop database on each volume.
- m463 6y agoit would be nice if there were more settings for this - external drives - non hfs/apfs drives - everywhere
- DiabloD3 6y agoI'm going to be honest: it should be deleted when seen, and OSX should have never begun this. 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?!
- nyanpasu64 6y ago> Why does git not automatically ignore that?! 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.
- skyzyx 6y agoJust add it to `~/.gitignore` and be done with it. Yeah haven’t worried about this in 10 years.
- manquer 6y agoThat approach works for one person or like minded dev teams perhaps. 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.
- hnarayanan 6y agoIt is easy to explain and help someone with this. :)
- 6y ago
- cjbprime 6y agoDS_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. 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.
- dannyw 6y agoWe have iCloud now and ETE encryption. The proportion of people plugging USB devices into machines they don't own is probably pretty minimal.
- lovelyviking 6y agoStill if you have pre calculated sizes of the folders, does it really matter what media was used to transfer data? Also I think people realising more and more that it'ss not very rational to trust to anyCloud with personal data. My rule is simply never use any cloud.
- IfOnlyYouKnew 6y agoMacOS does have the ability to store any arbitrary metadata in extended attributes, which would indeed seem to be a far better solution here. It doesn’t really bother me as it is, but it’s on the less-than-perfect list.
- lilyball 6y agoExtended attributes are lost by a lot of mechanisms of moving files and folders around (e.g. zipping them with something other than Finder's "Compress" command). It's also not portable to other filesystems, whereas a .DS_Store file will work on any filesystem.
- robomc 6y agothat seems fine?
- lilyball 6y agoLosing metadata by accident seems fine?
- ltbarcly3 6y agoThumbnails aren't metadata, they are a cache, since they can always be perfectly and deterministically recreated from the data.
- lilyball 6y agoThumbnails aren’t stored in .DS_Store.
- torstenvl 6y ago.DS_Store is not metadata. It is configuration information for Finder. It is not necessary for each computer looking at a set of files to use the same, e.g., icon size.
- fractallyte 6y agoThe Amiga had an equivalent: every visible icon was accompanied by a small metadata file appended with .info (More information here: http://krashan.ppa.pl/articles/amigaicons/ http://krashan.ppa.pl/articles/amigaicons/). But it didn't 'pollute' the filesystem, and was far more manageable. Haiku does things differently, and elegantly: https://medium.com/@probonopd/my-sixth-day-with-haiku-under-the-hood-of-resources-icons-and-packages-abec8d0e4ec6 https://medium.com/@probonopd/my-sixth-day-with-haiku-under-...)
- takeda 6y agoBecause the <name>.info was created by you (its major purpose was to have a custom icon to a program, drawer (directory) etc.). 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 :)
- ocdtrekkie 6y agoWindows has thumbs.db, but seems to do a reasonably good job not copying it into stupid places.
- dannyw 6y agoWindows still creates thumbs.db into my network drives. 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 :(
- bzb3 6y agofind -delete Might be helpful.
- efreak 6y agoWD MyCloud devices create a .wdmc directory in any folder that has images or videos. I've solved this issue at various times by adding a new file extension for mp4 files (mmp4, associate it with media player) until I changed apps to one that only displays video files; running a script after uploads to delete them; killing the service every time the NAS reboots (and I notice). Currently I'm using ftp instead of smb, as it doesn't seem to cause it and transfers faster as well--plus, ftp displays the hidden directories where smb doesn't.
- gardaani 6y agoAnd Linux Dolphin creates .directory files. Fortunately, there's a configuration option to turn it off. These kind of files seem to be usual for file managers. https://www.reddit.com/r/kde/comments/avmsdt/dolphin_is_great_but_directory_files_are_not/ https://www.reddit.com/r/kde/comments/avmsdt/dolphin_is_grea...
- deleted 6y ago[deleted]
- torstenvl 6y agoCould always add this to your crontab */20 * * * * root find / -name ".DS_Store" -depth -exec rm {} \;
- LeoPanthera 6y agoNo need for "-exec rm", you can use "-delete". And probably better to limit this to "~" rather than "/".
- torstenvl 6y agoI disagree. If anything, inside your home directory is the one place where .DS_Store files are potentially useful and not harmful. And -delete has limitations regarding files that aren't within the current working directory or its subdirectories (I don't know what the "current working directory" is for cron off the top of my head).
- boring_twenties 6y agoEven if that's true, you should use xargs, not -exec
- boring_twenties 6y agoThe Correct(tm) way: find [whatever] -print0 | xargs -0 rm
- toast0 6y ago.DS_Store is like the filesystem equivalent of 'Sent from an iPhone' --- it lets everyone know you used a Mac.
- muzani 6y agoI've always suspected this and the rest of the conversation confirms it.
- blihp 6y agoIt'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.
- pfranz 6y agoI think the problem is Finder long ago move away from spacial interface to a browser interface. Since the move wasn't very clear-cut it's now just bad at remembering position and layout. Not to mention those things aren't very useful on a completely different computer that would have a different resolution and screen layout. 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).
- lovelyviking 6y agoPersonally 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 ...
- torstenvl 6y agoStore your app's configuration, including per-folder view options, in a centralized store -- either ~/.dreamfm/ or ~/Library/Application Support/ Dream File Manager/ 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.
- lovelyviking 6y agoThank your for your thoughts. This is more or less how I see it too in general. > 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.
- undebuggable 6y ago.DS_Store is the new Thumbs.db. Our descendants will keep finding them in the backups and scratch their heads.
- deleted 6y ago[deleted]
- peglasaurus 6y agoWell, I could go on a rant around their purpose and some of us would ultimately decide these files like so many others are actually just debris. 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.
- enriquto 6y agoThese 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.
- t0astbread 6y ago"I hope operating systems keep putting up traps so that there's more ways to make mistakes"?
- enriquto 6y agoYes, I agree that this is a bad idea overall. However, since I'm not a macos user I couldn't care less.
- sesuximo 6y agoIf you’re enough of a power user to notice, then you should be able to figure out how to disable them. A quick google search finds several blog posts with commands to run.
- thealistra 6y agoDid anyone create a bug report for Apple I can duplicate? Apple usually prioritizes bugs by duplicate count.
- stakkur 6y agoHere's a brief and somewhat interesting explanation for why it exists, from Arno, the tech lead at the time (2006): https://www.arno.org/on-the-origins-of-ds-store https://www.arno.org/on-the-origins-of-ds-store