[slmjkdbtl]

I remember there used to ways to turn off the creation of .DS_Store but they removed it, I can't figure out for life why they would make such a change. I had to write a program [0] to watch the entire file system and delete .DS_Store as soon as they're created.

[0] https://github.com/slmjkdbtl/dskill

[js2]

You can turn it off for network volumes:

  defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE

https://support.apple.com/en-us/102064

I don't recall there ever being a way to turn it off for local volumes.

[nness]

I set up my samba config to veto .DS_Store files, which also seems to work (although not sure if it creates more overhead as MacOS tries to recreate it each time...)

[grishka]

Is it also possible to do this for removable media?

It seems to be the first time I'm seeing Apple themselves officially recommending a "defaults write" command.

[js2]

Not sure if this still works, but:

  defaults write com.apple.desktopservices DSDontWriteUSBStores -bool TRUE

Re: defaults:

https://support.apple.com/guide/terminal/edit-property-lists...

[silverwind]

There was https://github.com/binaryage/asepsis but Apple broke it IIRC.

[js2]

It was a hack, not anything Apple ever supported:

> 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.

[m463]

I apple really made a mess when they started adding .<stuff> in the root of a filesystem and never cleaned it up.

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

and quickly eject the drive before something else is written.

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.

[phyzix5761]

find / -name ".DS_Store" -exec rm {} \; 2>/dev/null

Put that in a script and add it to your crontab.

[fragmede]

-delete is faster

[phyzix5761]

Even better!

[mort96]

That's gonna be incredibly slow on most developer machines. node_modules, __pycache__, Cargo target/ folders, Yocto build folders, .git folders, etc etc etc -- all my machines which are ever used for development end up with such a gargantuan amount of small files across the filesystem that any operation which involves iterating through all of them takes forever.

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.

[phyzix5761]

Cool. This was a response to ops github repo which does the same as the command I commented with. Your use case is different.

[mort96]

That doesn't seem to be true? Looking at the C source code, it seems to be using fsevents to delete .DS_Store files when they're created, not periodically scan every single file on the system to delete .DS_Store files

[phyzix5761]

Ah ok. Thanks for pointing that out.

[akares]

> github.com/slmjkdbtl/dskill

You have a good coding style.

[gumby]

Why? I just ignore them.

[prurigro]

Google sent a copyright violation notice for each .DS_Store anyone at my company uploaded to Drive for nearly a year (yes, many support tickets were filed).

It wasn't Apple's fault, but it still would have been nice if there was a way to turn them off.

[heavyset_go]

That's scary considering how willingly they'll shutdown accounts for tripping their automated copyright violation service.

[prurigro]

For sure! I made sure to have an open ticket with them until it was resolved so I'd have someone to call if some other automated system decided to shut down our services for it.

[janalsncm]

Why? Somehow DS_Store is claimed as a copyrighted file?

[biztos]

White noise was claimed on YouTube[0].

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...

[Pikamander2]

The process likely went something like this:

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.

[Wowfunhappy]

> In theory, a Google engineer could code in a special case to avoid this problem

And then in this alternate universe, pirates start naming all of their files ".DS_Store"!

[prurigro]

That's a good question. I get the impression the system is fairly opaque even to the people working there. I was told it was "resolved" and had my ticket closed a bunch of times, only to have another 30+ copyright violation emails the next time someone uploaded a batch of files from MacOS.

If the person who finally managed to figure it out ends to reading this, thanks for the resolution :)

[gumby]

Holy cow, that’s crazy!

[rf15]

Missing Stair effect - ignoring a problem does make everything progressively worse for everyone because the problems pile up.

[demondemidi]

That’s the easy solution. But some people are absolute control freaks and would rather go nuts about a hidden file than actually spend their energy creating things. Very telling.

[DEADMINCE]

Some people can't.