>>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.
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.
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.
Curious what creative use cases people have around this bizarre file format. The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase
> The only reason myself and millions of other people have to deal with this stupid file is adding it to .gitignore as part of the ritual of spinning up a new codebase
I stole this from somewhere: Create a .gitignore_global file and include .DS_Store, then in the [core] of your .gitconfig include excludesfile = /Users/janedoe/.gitignore_global.
I instinctively delete these .DS_Store files whenever I see them but your "creative uses" comment makes me think given common .gitignore practice this might be a great place for AWS keys or whatever you never want checked into VCS /s
Having .DS_Store all over the place sucks, but to be fair so does having other dot files, such as .git which is an entire subdir even. At least the convention of hiding dot files from file listings is uniformly observed.
It's not exactly the same thing, but Windows used to have a thumb.db to store, well, thumbnails, in each folder that has thumbnail-able files.
I hated it, most of people hated it. MS finally got rid of it (in Vista or 7) and store thumbnails in a centralized place.
However, I now start to miss it.
I store lots of large image files (think 1200 dpi PNG scans) on my computer, and it took Windows years to create thumbnail for them, while locking the entire hard disk (and sometimes the whole explorer.exe) in the meantime. This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.
This would be fine if it's a one-time process, but unfortunately the aforementioned centralized thumbnail cache either have an expiration time, or have a size limit (or both), so the reality is if I didn't visit a folder for awhile, its thumbnails are all gone, so they have to be generated again, make the explorer unresponsive for some time again.
I have been annoyed by this for long time but I don't have any solution. The best workaround is to only view such folders in list/detail mode, and rely on 3rd party image manager (I use XnView) to show the preview/thumbnail -- which has a much faster thumbnailing speed and more robust thumbnail cache management.
> This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.
Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that performance sinkhole. Meanwhile I worked on a multiplatform project where macOS builds on a Mac mini for the exact same project took less than half the time to build than on a beefed up Windows workstation.
Here's an interesting discussion on HN from a couple of years ago on this topic.
My question is: Linux and Mac both have the ability to store key-value pairs on files/folders with xattr. Why did or does Apple continue to use .DS_Store?
Good question. Possibly because that approach wouldn't work on readonly files. (But in the case of readonly directories .DS_Store wouldn't work either).
Possibly because not all copy programs copy metadata.
Possibly it's just technical debt: .DS_Store was added to MacOS before xattr and rewriting the Finder to use xattr is not high priority.
This article makes me wonder: what tools do you use when reversing a custom file format?
Personally, having done so recently to reverse a custom game archive format, I have only used the usual hexdump, strings, grep, sed, etc. I'm wondering if there are more powerful tools to do this kind of job?
You usually want something for which you can define a structure and parse the file with it. There are a bunch of commercial and free tools, I've used the following with success in the past:
- 010 Editor (commercial)
- Kaitai Struct (free & open source)
Also has the advantage of directly generating parsers from the defined structures.
I don't think there's any way to do that, the files are needed by Finder to store per-folder layouts and settings.
You can however create a cronjob that deletes the files as often as you want, the operation takes 11 seconds on my 1TB SSD with a fairly large home folder:
I'm not aware of any reliable way, but anecdotally I've found that they seem to be mostly triggered by Finder usage, rather than the OS itself. I've gotten out of the habit of using Finder (instead mostly just use terminal or file-hierarchy UIs in whatever relevant app/IDE), and it's a long time since I've had a .DS_Store issue.
while we're here discussing what files should be pre-emptively added to your web server's deny entry; what else should be in there.. besides, say, .git?
I guess you could block .* except .well-known 'just in case'
[+] [-] m348e912|3 years ago|reply
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.
[+] [-] dreamcompiler|3 years ago|reply
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.
[+] [-] alin23|3 years ago|reply
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`:
[+] [-] CharlesW|3 years ago|reply
The Wikipedia article is a pretty good resource for this: https://en.wikipedia.org/wiki/.DS_Store
[+] [-] GeekyBear|3 years ago|reply
For the exact same reason Windows has a Desktop.ini file?
They store per directory settings for the Mac Finder and Windows Explorer.
[+] [-] Lt_Riza_Hawkeye|3 years ago|reply
[+] [-] gorgoiler|3 years ago|reply
(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.
[+] [-] SOLAR_FIELDS|3 years ago|reply
[+] [-] pilif|3 years ago|reply
People working on Linux or Windows do not need to know about garbage your dev env leaves on your machine.
I’m saying this half-seriously as I fully understand that these are so common, it’s more convenient to have the exclusion synced between clones.
That said, as a purist, none of the repos I’m watching over have .DS_Store in their gitignore
[+] [-] 50|3 years ago|reply
I stole this from somewhere: Create a .gitignore_global file and include .DS_Store, then in the [core] of your .gitconfig include excludesfile = /Users/janedoe/.gitignore_global.
[+] [-] planede|3 years ago|reply
[+] [-] whalesalad|3 years ago|reply
[+] [-] srhtftw|3 years ago|reply
[+] [-] tannhaeuser|3 years ago|reply
[+] [-] thrdbndndn|3 years ago|reply
I hated it, most of people hated it. MS finally got rid of it (in Vista or 7) and store thumbnails in a centralized place.
However, I now start to miss it.
I store lots of large image files (think 1200 dpi PNG scans) on my computer, and it took Windows years to create thumbnail for them, while locking the entire hard disk (and sometimes the whole explorer.exe) in the meantime. This process, while obviously is much slower on spinning HDD, it surprisingly isn't really that fast on NVME SSD, either.
This would be fine if it's a one-time process, but unfortunately the aforementioned centralized thumbnail cache either have an expiration time, or have a size limit (or both), so the reality is if I didn't visit a folder for awhile, its thumbnails are all gone, so they have to be generated again, make the explorer unresponsive for some time again.
I have been annoyed by this for long time but I don't have any solution. The best workaround is to only view such folders in list/detail mode, and rely on 3rd party image manager (I use XnView) to show the preview/thumbnail -- which has a much faster thumbnailing speed and more robust thumbnail cache management.
[+] [-] simplotek|3 years ago|reply
Windows is renowned for having awful performance in usecases involving accessing many small files even for read-only applications. I know a team that even went as far as testing switching away from Windows to build Windows apps and instead switched to cross-builds on Linux just to avoid that performance sinkhole. Meanwhile I worked on a multiplatform project where macOS builds on a Mac mini for the exact same project took less than half the time to build than on a beefed up Windows workstation.
Here's an interesting discussion on HN from a couple of years ago on this topic.
https://news.ycombinator.com/item?id=18783525
[+] [-] mdmglr|3 years ago|reply
More info here: https://superuser.com/a/298798
My question is: Linux and Mac both have the ability to store key-value pairs on files/folders with xattr. Why did or does Apple continue to use .DS_Store?
[+] [-] dreamcompiler|3 years ago|reply
Possibly because not all copy programs copy metadata.
Possibly it's just technical debt: .DS_Store was added to MacOS before xattr and rewriting the Finder to use xattr is not high priority.
[+] [-] flomo|3 years ago|reply
But at the very least, they could set the FAT hidden attribute on this stuff. It must be some mentality like "Well, I'm not littering in my own yard?"
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] kakwa_|3 years ago|reply
Personally, having done so recently to reverse a custom game archive format, I have only used the usual hexdump, strings, grep, sed, etc. I'm wondering if there are more powerful tools to do this kind of job?
[+] [-] eXpl0it3r|3 years ago|reply
- 010 Editor (commercial)
- Kaitai Struct (free & open source)
Also has the advantage of directly generating parsers from the defined structures.
[+] [-] pabs3|3 years ago|reply
http://fileformats.archiveteam.org/wiki/Desktop_Services_Sto...
[+] [-] eviks|3 years ago|reply
[+] [-] nielsbot|3 years ago|reply
[+] [-] _ZeD_|3 years ago|reply
I'm on Big Sur (11.7.1) and I didn't find a way to make finder NOT create them.
It's (one of the many) irritating idiosyncrasies of this OS
[+] [-] alin23|3 years ago|reply
You can however create a cronjob that deletes the files as often as you want, the operation takes 11 seconds on my 1TB SSD with a fairly large home folder:
obviously, remove the echo to actually delete the files[+] [-] lucideer|3 years ago|reply
[+] [-] suction|3 years ago|reply
[deleted]
[+] [-] ehPReth|3 years ago|reply
I guess you could block .* except .well-known 'just in case'
[+] [-] tetha|3 years ago|reply
[+] [-] Dalewyn|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] dancemethis|3 years ago|reply
[+] [-] lapcat|3 years ago|reply
[+] [-] saagarjha|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]