Huh, macOS includes a utility called `dot_clean`. It's just been sitting there, quietly, in `/usr/sbin` for decades waiting for me to discover.
I've been using macOS since it was OS X and thought I knew most of its nooks and crannies. Today I learned a new one.
When I was first introduced to Unix in the mid-90s, one of the things I did was to poke around all the bin dirs, see what was there, read most of the man pages. I'm not sure I ever bothered to do that on OS X. Maybe it's time.
buildbot 33 days ago [-]
For whatever reason both macos and freebsd have this effect. So many useful, mystery binaries.
Macos does sometime ship cool cli tools deep in the built in Apps which makes discovery harder.
ryandrake 33 days ago [-]
Very, very nice and helpful! I probably wouldn't do it exactly this way on my system, but it's always good to see other approaches to this annoying and entirely unnecessary problem. One of my biggest pet peeves about macOS is its tendency to leave its "droppings" all over my SD Card filesystems and network shares, and I'm constantly searching for a nice clean, transparent way to fix this bug since Apple seems to have no intention of doing it themselves. So rude to be using my filesystem as their personal dumping ground for crap.
I would add ".fseventsd" and ".Spotlight-V100" folders to the cleanup targets, too.
Appears to work fine for me. No files created on network or usb storage.
ryandrake 33 days ago [-]
Tried these so many times and they never seem to persist. Eventually, I'll start noticing the junk files coming back and lo and behold the defaults are no longer set.
dylan604 33 days ago [-]
Assuming you mean persist after OS upgrades/updates? As bad as OS updates overwriting user's settings, having them persist less time than that would be very disconcerting.
pixelesque 33 days ago [-]
It's not always just "foreign" filesystems where it happens.
I hooked up my MBPro to my two Linux machines with Syncthing, and suddenly I had .DS_Store files in all my shares directories on both of those Linux machines.
I then had to set up .stignore files to ignore the further syncing of them and also had to iradicate the files manually.
My Syncthing shares were in my $HOME/Sync/ directory on my MBPro (M2), which should be the main drive mount as far as I'm aware?
pixelesque 33 days ago [-]
Also: the way I discovered this was that one of the directories was the shared directory for my website blog (both source and target static-site generated files), and from my Linux machine I had r-synced that to my remote web server, and noticed bots had found these .DS_Store files in most directories of my website, which included (due to the .DS_Store files) unlinked files which the crawlers wouldn't have found if not for the .DS_Store files.
So I was then getting 200 HTTP requests on the .DS_Store files and I noticed that in my server logs, and then it occurred to me how they had got there (via Syncthing, and me not noticing them locally on the Linux machines until I looked for them and found them).
Joel_Mckay 33 days ago [-]
Did you try a filter like rsync's
--exclude=".*/"
Or an Apache regex config like:
<FilesMatch "^\.">
Order allow,deny
Deny from all
</FilesMatch>
Or something like:
RewriteRule ^(.*/)?\.git+ - [R=404,L]
RedirectMatch 404 ^(.*/)?\.git+
Good luck =3
wheybags 33 days ago [-]
Why does apple still do this? Surely there's some other way they can implement whatever functionality these files provide? The collective number of man hours wasted on this issue is probably centuries by this point.
tpmoney 32 days ago [-]
As far as I know, not in a way that’s portable across file systems. My understanding is these files persist information about the view of the directory. Things like icon positions, whether it is viewed as a list or as icons etc. All options are a tradeoff in some way.
You could persist it in a DB on the machine itself, but then every machine would have a different view and you might lose that between machines or on upgrades. The classic app icon + arrow image + applications folder alias with some basic text instructions in the window for installing an app via drag and drop (and for that matter sizing the window to have all of that nicely framed in view) is all in this data. A per-machine setting would mean app developers couldn’t store that data with the install image, or it would require disks themselves to be carriers of that data / special file systems for software install disk images.
Per file metadata a la the classic Mac resource fork is an option, but osx moved away from that precisely because only HFS supported it and other OSes and systems would silently drop the fork. Not a problem in a pre-interconnected computing world, but a huge problem in a world where your file might pass through multiple file systems on its way to you. That’s one of the reasons why classic Mac software archives still hold everything in .sit files, since that keeps the resource fork intact for the contents while being storable on non-HFS file systems.
And the choice they have gone with (per directory hidden files) has the downside of littering systems with misc files that other users don’t care about
reaperducer 33 days ago [-]
Why does apple still do this?
It's been 20 years since I moved from Windows to Macintosh, and I still run occasionally run into Thumbs.db files.
sorenjan 32 days ago [-]
But unlike Apple, Microsoft stopped using Thumbs.db in Vista, 18 years ago.
Y-bar 32 days ago [-]
Probably for a reason similar to why Microsoft won't change this behaviour: "Zone.Identifier Files when downloading from Windows to WSL file structure" (https://github.com/microsoft/WSL/issues/7456)
xmasterdev 28 days ago [-]
[dead]
32 days ago [-]
giancarlostoro 33 days ago [-]
I personally don't care, its just tiny files, Windows does similar with Thumbs.dll or whatever, I use git for important things which usually adds these files to my git ignore, but apparently sometimes these type of file leaks can lead to websites being hacked, since .DS_Store contains information about files in the current working directory, so if you say, upload a SQL script you use to migrate and it has a root password on it, an attacker might now know where that is on your web server.
I've been using macOS since it was OS X and thought I knew most of its nooks and crannies. Today I learned a new one.
When I was first introduced to Unix in the mid-90s, one of the things I did was to poke around all the bin dirs, see what was there, read most of the man pages. I'm not sure I ever bothered to do that on OS X. Maybe it's time.
Macos does sometime ship cool cli tools deep in the built in Apps which makes discovery harder.
I would add ".fseventsd" and ".Spotlight-V100" folders to the cleanup targets, too.
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool TRUE
Appears to work fine for me. No files created on network or usb storage.
I hooked up my MBPro to my two Linux machines with Syncthing, and suddenly I had .DS_Store files in all my shares directories on both of those Linux machines.
I then had to set up .stignore files to ignore the further syncing of them and also had to iradicate the files manually.
My Syncthing shares were in my $HOME/Sync/ directory on my MBPro (M2), which should be the main drive mount as far as I'm aware?
So I was then getting 200 HTTP requests on the .DS_Store files and I noticed that in my server logs, and then it occurred to me how they had got there (via Syncthing, and me not noticing them locally on the Linux machines until I looked for them and found them).
--exclude=".*/"
Or an Apache regex config like:
<FilesMatch "^\.">
</FilesMatch>Or something like:
RewriteRule ^(.*/)?\.git+ - [R=404,L]
RedirectMatch 404 ^(.*/)?\.git+
Good luck =3
You could persist it in a DB on the machine itself, but then every machine would have a different view and you might lose that between machines or on upgrades. The classic app icon + arrow image + applications folder alias with some basic text instructions in the window for installing an app via drag and drop (and for that matter sizing the window to have all of that nicely framed in view) is all in this data. A per-machine setting would mean app developers couldn’t store that data with the install image, or it would require disks themselves to be carriers of that data / special file systems for software install disk images.
Per file metadata a la the classic Mac resource fork is an option, but osx moved away from that precisely because only HFS supported it and other OSes and systems would silently drop the fork. Not a problem in a pre-interconnected computing world, but a huge problem in a world where your file might pass through multiple file systems on its way to you. That’s one of the reasons why classic Mac software archives still hold everything in .sit files, since that keeps the resource fork intact for the contents while being storable on non-HFS file systems.
And the choice they have gone with (per directory hidden files) has the downside of littering systems with misc files that other users don’t care about
It's been 20 years since I moved from Windows to Macintosh, and I still run occasionally run into Thumbs.db files.
Here's an article from 2010
https://www.intego.com/mac-security-blog/possible-security-i...
Here's one from 2021 where Microsoft leaked credentials:
https://cybernews.com/security/microsoft-vancouver-leaking-w...