For example almost all electron apps keep the last two or so versions around when they auto-update. And since Electron apps are around 250 MB that's 0.5 GB of old versions per app.
I recently discovered a big cache - in terms of file number, 6000 files - of basically every edit I did in the last 6 months in VS Code - called Local History. Also, every directory you launch VS Code in will have a workspace cache associated with it, it can be 200 MB if you have C++ files in it, and VS Code will not remove it when you delete the original dir.
And so on...
I wish they would all integrate into a master clear caches system app, where you would have the opportunity of seeing them and clearing them. A bit like on Android.
Xcode is a huge offender, at least for me. At 36GB, not only is it the largest application in my Applications folder (it is larger than all my other applications combined), it also litters /Library/Developer with about 9GB of shit (mostly simulator runtimes), and then litters ~/Library/Developer with 33GB of shit (mostly caches). Almost 80GB disk footprint... just to develop software?
I find it so embarrassing because every dev gets fed this culture. Or take the insane update sizes. Os or Xcode. Or the upload to the app store useing bandwidth several times the binary size. An app that used to be .5MB in objc is now in swift 15MB tesflight, 70MB production ipa and 300MB upload traffic.
That's what sustainability looks like in the eyes of a hardware supplier.
Xcode is actually only about 17 GB on disk, assuming you haven’t copied it anywhere. When it’s installed transparent APFS compression is applied to the bundle.
> I recently discovered a big cache - in terms of file number, 6000 files - of basically every edit I did in the last 6 months in VS Code - called Local History.
Isn't this a feature? I wouldn't want my editor to remove my local history without me knowing. I frequently use this local history (in Intellij), for whatever reason (it's easier than git, the project doesn't have version control, I haven't committed yet, ...)
6 months is a very long time for this though. I imagine that I would almost never want local history past a day or two. Beyond that I would look to my version control system.
There should be one directory where all apps keep caches in subdirectories, managed by the operating system, evicting cached files as necessary using some LRU policy. (MacOS has well-defined cache directories, but nothing managing them.)
Likewise for system RAM. Lots of apps are using RAM to cache with no way to coordinate.
I once had a Photos library that consumed 250 Gb - for 80 Gb worth of photos. Thankfully there was some third party software that could automatically export and reimport all photos (it took hours), which shrank the library back to its actual size.
I really wish OSes would stop using my filesystem as a dumping ground for rando metadata their developers keep generating and finding no other place for. Between .DS_Store, .Trash, desktop.ini (on Windows), and all these various "caches" garbage heaps they randomly dump into my directories, I feel I have less and less control over what I'm keeping on my own hard drive by default. A hard drive that I purchased, not some developer in Cupertino.
Yes, I know some of these can be turned off if you dig deep enough in settings, but the behavior should not be on by default.
Given that people expect their folders in MacOS to leave things where they put them and the fact that .DS_Store files aren’t visible by default, I can’t agree with you.
It ensures that these settings carry over regardless of what actions you take on the directories and is low complexity. It seems much more preferable to me than a centralized database to track and maintain all the changes and is not portable.
I do think it should be an option to disable them, but to suggest that it shouldn’t be on by default is asinine. They’re serving the broader population, not grumpy nerds.
Storage is cheaper and faster than ever. How does this metadata affect you? You make it sound as if they’re *exploiting* your very important disk space for their own malicious purposes.
This content is there to store things like folder views, which for many people is pretty useful.
It’s unfortunate that they didn’t consult you prior to designing it like this, but they did offer the option of disabling it.
I take little issue with .DS_Store because it's located where you expect. What I do have an issue with, are cached files that hide in folders that are unknown to me.
I got a MacBook Air 2020 with 128GB storage to use mostly for browsing and light dev and that quickly filled up. It's like the OS tries to obsolete the machine as quickly as possible. The biggest annoyance is Finder telling me most of the storage is used by "Other".
The iPhone is doing the same. The unremovable caches will kill your space with time.
I remember the Apple Music app caching and never removing any songs you’ve listened to and not showing any space it uses in settings.
But this behavior is not specific to the Apple Music app - any other can do it too. Any caches from social apps you use have a high chance of being untraceable - it all goes into "Other".
Why? Try buying a model with a higher capacity to get an answer.
I also saw this behavior with an Android device - where removing a messenger on my grandfather’s phone freed up 20+ GB of space.
> I remember the Apple Music app caching and never removing any songs you’ve listened to and not showing any space it uses in settings.
Wait—really? I don't use Apple Music, but surely with heavy use, you could easily end up with a cache that's hundreds and hundreds of gigabytes large...
What's the timescale here, for "The unremovable caches will kill your space with time". I'm currently holding an iPhone 11 running the iOS 16 beta, that I got in October of 2019. Looking at Storage, I'm sitting at 67GB used of 256GB. The heavy hitter app-wise is Spotify at 13GB, but that's all music that I specifically told it to keep locally. "Other System Data" is 22GB.
They were, and still are viable devices to some people. I only upgraded from a 128gb mbp and a 16gb iphone this year, after using them for 7 and 6 years respectively. Storage was never an issue with the laptop, and only became a problem with the iphone in the last couple of years.
As someone with a 128 GB model, I manage just fine. This is not the same as selling 16 GB models 3 or so years ago (that was ridiculous). It’s only a “scam” if you’re someone that needs more space and thinks having a “just fine” lower tier is a scam.
There's a useful Apple-created tool built right into the OS:
1. Cmd-space for Spotlight
2. Type Storage Management
3. Hit Review Files
Now you can sort by largest files and quickly make an impact on space used.
The only problem I had with Apple's storage management utility is that it kept reporting a Steam game using 27G when that game was long deleted (and Steam itself was deleted). To resolve this, I had to go to the ~/Library/Application Support directory and completely remove the Steam folder (which didn't actually have that 27G game anywhere in it.)
My longstanding favorite for this has been OmniDiskSweeper[0]. It's dead simple and I've been using it for just about the entirety of OS X's existence.
It’s borderline criminal that these were sold with soldered-on SSD’s that can never be upgraded. It makes piles of otherwise completely useful laptops unusable pieces of shit. Same with the RAM.
The environmental damage alone that comes from this practice is heart wrenching. No possible performance benefits can be worth the damage it does.
“Other” is probably 90% from ~/Library/Application Support/. Because apps like Chrome are too lazy to split things out of there to make them legible to the OS — e.g. putting their cache dirs under ~/Library/Caches/, etc.
i'm amazed that they still sell/sold 128gb versions that late. I remember deciding never to get a computer with that small a hard drive again a bit less than 10 years ago. it clutters up so fast.
I've given up... Now I always order the 4TB option with any new mbp I order. Like this I never have to think about diskspace. I know for a fact that there's a lot of useless junk that I shouldn't need. I know that devs are lazy about cleaning up disk space and long are the days of my 120mb hard disk on my 486 but after struggling with disk space growing uncontrollably in a 1TB ssd, I just can't be bothered dealing with that.
By doing this, I'm part of the problem. By not establishing boundaries and refusing to install apps like Xcode that are programmed to put as much trash as possible, I contribute to making it acceptable for developers to treat us like this but it's a fight I'll admit I've lost.
I feel you. My macbooks have always reached the point of feeling very cramped for storage and I find myself juggling for disk space more often than I'd like. This is mostly because I simply won't pay an extra thousand dollars - what Apple charges for maxed storage in my currency.
I recently ordered a Framework laptop. It's yet to arrive, but I'm already excited about the fact that I could just order a very large, very fast, top of the line NVMe drive from a PC parts vendor for only a few hundred dollars.
Instead of getting a bigger internal disk, I opted for an external USB-C drive. The one I got (SanDisk Portable SSD) has 2TB of storage and transfers data at 1GB/s, so fast enough for everyday uses. I use it mostly for cold storage of larger files I rarely need and backups. So instead of spending $600 on the internal 2TB, my external drive only cost me $200 and is small enough to fit into any pocket.
I'm not by any means a regular user of macOS but whenever I've had to use it, it's had the impression of a sleek and elegant face with much worse below the surface, and this is no different.
It makes sense to make a copy when you set an image as a wallpaper, but what doesn't make sense is to keep that copy (with an automatically generated unique name!?!?) even after another wallpaper is set.
But, looking at the "wrong way" and guessing at the implementation, I have an idea how this happened: "Share" makes a copy with a unique name, presumably to avoid conflicting with anything else, and then tells the OS to set that as the wallpaper.
I wouldn't even call this a "cache", but a "leak".
Everything is a mess under the surface. It's more or less impossible to write something as complex as a modern desktop OS and keep all your code and behavior neat and tidy.
It's not really TTL that's needed here, it's a notion of file/directory tree priority integrated with the filing system APIs. Think about it: there's no reason not to use every single byte of your disk. The only reason we have to leave so much empty space as padding today and manage it so manually is because the OS itself won't automatically delete unimportant files when needed. If it did then apps could just generate caches with abandon safe in the knowledge that they'd be overwritten when necessary. Also, the user would always see the "true" amount of free space, i.e. actual space - caches - tmp files.
This is perfectly elegant. The desktop picture and the photos for it are segmented from the rest of the system in a container (similar to Virtual Locations on Windows) that the app can access instead of letting every random app access all your files at once without you having any control about it.
Regarding caching: generally, it's up to each individual developer (and sometimes even different teams within a company) to do this right. The only place where developers are 'forced' to do it right is '/tmp/' because that is supposed to get nuked every reboot.
that the app can access instead of letting every random app access all your files at once without you having any control about it.
That has nothing at all to do with this idiocy of using a different name every time, and not even thinking that it could be a problem to automatically create effectively "orphaned" files that no one would know about until it's too late.
The actual folder is "/System/Library/Desktop\ Pictures", but it's protected on newer systems. It consumes 414MB on my machine, which is 0.3% of a 128GB drive. Doesn't seem worth the trouble to me.
BTW, I found the path by double-clicking the folder as seen in Desktop & Screen Saver, then dragged that selected Finder folder to a terminal window.
No, this is the wallpapers folder used to store all the default macOS wallpapers, not a cache folder, don’t delete it (if you don’t want to delete all the macOS stock wallpapers).
>> The folder path is: Macintosh SSD > Users > [yourHome] > Library > Containers > Photos > Data > Library > Application Support > Photos Desktop
> The folder path is: Macintosh SSD/Users/[yourHome]/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop
The $PATH is ~/Library/Containers/Photos/Data/Library/Application\ Support/Photos\ Desktop/
I have no idea what, if anything, is there, but this was bothering me. You almost had it, though, and I have no clue where the idea of using " > " as a $PATH separator came from, some kind of 1337 vppdpp h4x0r group maybe, but it's crazy.
Because it's a `Library/Application Support` folder within `~/Library/Containers/`, I wonder if this a feature hastily ported to macOS's sandboxing system.
(TBH I know nothing of how macOS implements its sandboxing system)
~/Library/Containers/* is where sandbox containers live. The folder structure within the container intentionally matches up with the folder structure non-sandboxed apps use, where the Data subfolder looks very similar to the user's home folder. I've never tested but I assume that sandboxed apps that call the macOS API that returns the user's home folder are actually given the path to their container's data folder instead. This makes it a lot easier to sandbox apps.
Ugh, I got bitten by this recently. I have a little program that downloads the latest satellite imagery from NOAA [1] and sets it as my desktop background every 5 minutes. One day I was wondering where the heck all my storage went...and found a 200GB wallpaper cache.
Readit News
For example almost all electron apps keep the last two or so versions around when they auto-update. And since Electron apps are around 250 MB that's 0.5 GB of old versions per app.
I recently discovered a big cache - in terms of file number, 6000 files - of basically every edit I did in the last 6 months in VS Code - called Local History. Also, every directory you launch VS Code in will have a workspace cache associated with it, it can be 200 MB if you have C++ files in it, and VS Code will not remove it when you delete the original dir.
And so on...
I wish they would all integrate into a master clear caches system app, where you would have the opportunity of seeing them and clearing them. A bit like on Android.
I use it almost weekly to clear out the tens of gigabytes of garbage Xcode regularly generates.
That's what sustainability looks like in the eyes of a hardware supplier.
I'll flush it, from time to time. I may also delete old archives. I have hundreds of them.
Deleted Comment
Isn't this a feature? I wouldn't want my editor to remove my local history without me knowing. I frequently use this local history (in Intellij), for whatever reason (it's easier than git, the project doesn't have version control, I haven't committed yet, ...)
Of course if the data is small why not keep it.
Deleted Comment
Likewise for system RAM. Lots of apps are using RAM to cache with no way to coordinate.
Nevertheless, I soon stopped using Photos...
Yes, I know some of these can be turned off if you dig deep enough in settings, but the behavior should not be on by default.
It ensures that these settings carry over regardless of what actions you take on the directories and is low complexity. It seems much more preferable to me than a centralized database to track and maintain all the changes and is not portable.
I do think it should be an option to disable them, but to suggest that it shouldn’t be on by default is asinine. They’re serving the broader population, not grumpy nerds.
Dead Comment
This content is there to store things like folder views, which for many people is pretty useful.
It’s unfortunate that they didn’t consult you prior to designing it like this, but they did offer the option of disabling it.
Deleted Comment
I remember the Apple Music app caching and never removing any songs you’ve listened to and not showing any space it uses in settings.
But this behavior is not specific to the Apple Music app - any other can do it too. Any caches from social apps you use have a high chance of being untraceable - it all goes into "Other".
Why? Try buying a model with a higher capacity to get an answer.
I also saw this behavior with an Android device - where removing a messenger on my grandfather’s phone freed up 20+ GB of space.
I learned that the hard way after a NY to Miami road trip when I binged “Hardcore History”
Wait—really? I don't use Apple Music, but surely with heavy use, you could easily end up with a cache that's hundreds and hundreds of gigabytes large...
They were all a borderline scam and even after deleting GarageBand etc the usable space was close to broken.
Sorry but this line only existed to force people who know it’s a scam to pay $100 more
Same deal with the 16gb iPhone lines.
1. Those with few big things - these people just don't need a lot of disk space
2. Those with lots of big things - no matter what you do your laptop can't hold everything, so you have a different place for the overflow anyway.
Personally, I think 128GB is crazy small, but it's been working fine for my wife for years, so what do I know?
1. Cmd-space for Spotlight
2. Type Storage Management
3. Hit Review Files
Now you can sort by largest files and quickly make an impact on space used.
The only problem I had with Apple's storage management utility is that it kept reporting a Steam game using 27G when that game was long deleted (and Steam itself was deleted). To resolve this, I had to go to the ~/Library/Application Support directory and completely remove the Steam folder (which didn't actually have that 27G game anywhere in it.)
[0]: https://www.omnigroup.com/more/
The environmental damage alone that comes from this practice is heart wrenching. No possible performance benefits can be worth the damage it does.
By doing this, I'm part of the problem. By not establishing boundaries and refusing to install apps like Xcode that are programmed to put as much trash as possible, I contribute to making it acceptable for developers to treat us like this but it's a fight I'll admit I've lost.
I recently ordered a Framework laptop. It's yet to arrive, but I'm already excited about the fact that I could just order a very large, very fast, top of the line NVMe drive from a PC parts vendor for only a few hundred dollars.
It makes sense to make a copy when you set an image as a wallpaper, but what doesn't make sense is to keep that copy (with an automatically generated unique name!?!?) even after another wallpaper is set.
But, looking at the "wrong way" and guessing at the implementation, I have an idea how this happened: "Share" makes a copy with a unique name, presumably to avoid conflicting with anything else, and then tells the OS to set that as the wallpaper.
I wouldn't even call this a "cache", but a "leak".
Like why did we have it for cookies and not localstorage or Indexdb?
Is there any filesystem with ttl support?
you could emulate that with $ find, but expiring stuff will require quite a mind-shift, I guess.
I do similar for mp3 recordings at https://codeberg.org/mro/internet-radio-recorder/src/commit/...
Regarding caching: generally, it's up to each individual developer (and sometimes even different teams within a company) to do this right. The only place where developers are 'forced' to do it right is '/tmp/' because that is supposed to get nuked every reboot.
That has nothing at all to do with this idiocy of using a different name every time, and not even thinking that it could be a problem to automatically create effectively "orphaned" files that no one would know about until it's too late.
Certainly isn't a ~/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop in my home.
I suspect it gets formed, when we use the Photos App to set the desktop.
I have always used the PrefPane.
BTW, I found the path by double-clicking the folder as seen in Desktop & Screen Saver, then dragged that selected Finder folder to a terminal window.
No, this is the wallpapers folder used to store all the default macOS wallpapers, not a cache folder, don’t delete it (if you don’t want to delete all the macOS stock wallpapers).
> The folder path is: Macintosh SSD/Users/[yourHome]/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop
The $PATH is ~/Library/Containers/Photos/Data/Library/Application\ Support/Photos\ Desktop/
I have no idea what, if anything, is there, but this was bothering me. You almost had it, though, and I have no clue where the idea of using " > " as a $PATH separator came from, some kind of 1337 vppdpp h4x0r group maybe, but it's crazy.
(TBH I know nothing of how macOS implements its sandboxing system)
Dead Comment
[1]: https://cdn.star.nesdis.noaa.gov/GOES16/ABI/CONUS/GEOCOLOR/l...
Regularly, on a random basis, it will forget my wallpaper selection and revert to one of the stock ones.
Intel or M1, it's been like this for years.
Not sure how hard it is to preserve my selection here, but ok.