Comment by slmjkdbtl
2 years ago
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.
You can turn it off for network volumes:
https://support.apple.com/en-us/102064
I don't recall there ever being a way to turn it off for local volumes.
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...)
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.
Not sure if this still works, but:
Re: defaults:
https://support.apple.com/guide/terminal/edit-property-lists...
There was https://github.com/binaryage/asepsis but Apple broke it IIRC.
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.
1 reply →
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:
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.
find / -name ".DS_Store" -exec rm {} \; 2>/dev/null
Put that in a script and add it to your crontab.
-delete is faster
Even better!
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.
Cool. This was a response to ops github repo which does the same as the command I commented with. Your use case is different.
2 replies →
> github.com/slmjkdbtl/dskill
You have a good coding style.
Why? I just ignore them.
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.
That's scary considering how willingly they'll shutdown accounts for tripping their automated copyright violation service.
1 reply →
Why? Somehow DS_Store is claimed as a copyrighted file?
4 replies →
Holy cow, that’s crazy!
Missing Stair effect - ignoring a problem does make everything progressively worse for everyone because the problems pile up.
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.
Some people can't.