defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
I don't recall there ever being a way to turn it off for local volumes.
> At core Asepsis provides a dynamic library DesktopServicesPrivWrapper which gets loaded into every process linking against DesktopServicesPriv.framework. It interposes some libc calls used by DesktopServicesPriv to access .DS_Store files. Interposed functions detect paths talking about .DS_Store files and redirect them into a special prefix folder. This seems to be transparent to DesktopServicesPriv.
> Additionally Asepsis implements a system-wide daemon asepsisd whose purpose is to monitor system-wide folder renames (or deletes) and mirror those operations in the prefix folder. This is probably the best we can do. This way you don’t lose your settings after renaming folders because rename is also executed on folder structure in the prefix directory.
Unsurprisingly, you can no longer do anything like this with SIP. If you're willing to disable SIP, there are forks of the project that apparently still work.
It seems to be the first time I'm seeing Apple themselves officially recommending a "defaults write" command.
defaults write com.apple.desktopservices DSDontWriteUSBStores -bool TRUE
https://support.apple.com/guide/terminal/edit-property-lists...
I can see after .DS_Store was allowed, it was no problem for other engineers to approve .fseventsd or .Spotlight-V100 or other nonsense that has cropped up over the years.
And I can't tell you how many filesystems I've had "corrupted" with these sorts of files.
Mostly SD cards, usb flash drives, but occasionally something horrible.
for these kinds of things I usually run:
rm -rf .DS_Store .Trashes ._.Trashes .fseventsd .Spotlight-V100
If you've had a disk that is going bad and you need to copy stuff off of it, the LAST thing you want is to index the whole thing and start writing to it.
seriously, there should be a setting.
Put that in a script and add it to your crontab.
Besides, there are .DS_Store I really don't wanna delete. Notably, there are git repos which have erroneously committed .DS_Store files; I don't wanna make those repos dirty by deleting them.
You have a good coding style.
It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.
When is someone going to copyright .gitignore? You could register gitignore.me right now! Fame, riches, lunch with Myhrvold[1][2]!
[0]: https://www.bbc.com/news/technology-42580523
[1]: https://en.wikipedia.org/wiki/Intellectual_Ventures
[2]: https://www.amazon.com/Modernist-Cuisine-Science-Stainless-S...
If the person who finally managed to figure it out ends to reading this, thanks for the resolution :)
1. Pirates uploaded a folder full of copyrighted files to Google Drive, accidentally including some DS_Store files along with the actual media.
2. The copyright owner filed a DMCA takedown on the whole folder, accidentally claiming ownership of a bunch of generic DS_Store files.
3. The above two steps have likely happened many times, not just once.
4. Google's takedown system now automatically flags DS_Store files as having multiple copyright violations.
5. A Google employee might be able to whitelist a user's individual DS_Store files to temporarily suppress the violation on their account, but since they can appear in different folders with different data and are constantly receiving new copyright claims, their system likely errs on the side of caution and continues to flag them as copyright violations so that Google doesn't accidentally lose its safe harbor protections.
In theory, a Google engineer could code in a special case to avoid this problem, but good luck finding and talking to one who's authorized to do so; Google is notorious for having one of the lowest employee;revenue ratios in the world and writing useless FAQs instead of having a proper support channel for when things go wrong.
And then in this alternate universe, pirates start naming all of their files ".DS_Store"!