>>Apple's operating system creates this file in apparently all directories to store meta information about its contents. In fact, it contains the names of all files (and also directories) in that folder.
Anyone have an idea why modern versions of MacOS still uses a .DS_Store file? The OS could just as easily read and display the contents of a directory. And deleting a .DS_Store file doesn't seem to have any noticeable negative affect.
.DS_Store is not part of HFS+ or APFS. It's a kludge to give the OSX Finder a place to store its own metadata.
MacOS prior to X had much more elegant solutions to the problem. To this day, when you switch to/from icon/list view in the Finder, more windows than just the current one switch. In MacOS 9 that loosey-goosey unpredictable behavior never happened.
> To this day, when you switch to/from icon/list view in the Finder, more windows than just the current one switch
And there's almost no way to make this behavior stick because... it's different if you click through folders and if you click on pinned folders in Finder sidebar.
Don't even get me started on the "Upload" dialog that can't remember that I want it to show dates and sort by them. It resets every time to the worst possible view - list, sorted alphabetically. So annoying. All other desktop OSes I've used got the upload windows remembering their settings, but not MacOS. Maybe the technology is just not there yet.
The file is used for storing layouts (show as icons/list/grid etc.) and various settings (sorting, grouping etc.).
Storing a local file inside the directory allows for moving that directory around while also keeping those settings.
The file is invisible for users of Finder so it is still the best solution for this task.
I have a .DS_Store line in a global .gitignore and don't notice it much but when I'm annoyed by DS_Store files in a specific directory, I usually bulk delete them using `fd`:
I believe if you've dragged some files around in that folder, it stores where those were. Or if you've set the folder to sort by name or date modified, etc.
One thing I've wondered is if this method still makes sense on modern hardware compared to keeping all that information in a centralized sqlite file or something along those lines. I could see individual files being advantageous on a slow mechanical HD where seeking through a file that could eventually grow large might pose issues, but that shouldn't be a problem on an SSD.
The main advantage I can think of that might still be relevant today is that it makes Finder window state machine-independent, so when you open a folder on two different machines it'll still open in list mode sorted by Date Modified or whatever.
I'm pretty sure it creates (used to? At least with XP) an ini file to remember the position of files in a folder if you manually arrange them, as well as to save view preferences (list, grid, tree) if you enable it per-directory.
I think Windows 7 (or thereabouts) ditched the Thumbs.db thumbnail cache file for each directory for a centralised file. Not sure what the reasoning was.
I've noticed that the .DS_Store file doesn't appear in a directory until I've clicked the triangle in a list view to see the contents of a subfolder. Then it creates one, I assume, to keep track of which subfolders are open.
Correct. If you create a new directory in the Terminal and populate it, it won't have a .DS_Store file. The Finder creates .DS_Store when you view the directory in the Finder.
I think you're right that .DS_Store handles labels, but custom icons are done with a second invisible file in the folder titled "Icon?" which apparently stores the icon data in its resource fork.
Labels and custom icons on files are stored in extended attributes (implemented as named forks on HFS+; not sure about APFS but the OS presents them all as xattrs regardless of FS) on the files themselves in APFS and HFS+.
Custom icons for folders are stored in a special "Icon?" hidden file, but not actually in the file's normal data-- they're in an extended attribute too.
(The xattr in question is called "com.apple.ResourceFork" and I'm presuming is structurally similar to a resource fork in classic Mac OS.)
If you know what a dotfile is, it’s there for the same reason.
(Dotfiles are per-user system configuration options written as a file in the user’s home directory. This means that for any system on which that home directory exists, that user’s configuration options will be applied. If the home directory is shared across multiple computers over a network, or if it is backed up from one computer and restored
to another, then that user’s settings will persist.)
If these settings were stored in some other central database then if you copied the macOS folder from one computer to another, your copy tool would have to know how copy the settings as well. Keeping those settings inside the folder itself means that your copy tool only needs to know about copying folders, instead of copying folders and also copying settings.
It’s one of those Unix principles where everything is treated as a file: an elegant technique for a more civilized age.
Anyone have an idea why modern versions of MacOS still uses a .DS_Store file? The OS could just as easily read and display the contents of a directory. And deleting a .DS_Store file doesn't seem to have any noticeable negative affect.