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 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, ...)
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".
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.
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.
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.
>> 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)
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.
But ... it boggles my mind how someone can change their wallpaper in my mind) 435 times in roughly 3 years. That's a new image every (365 * 3) / 435 = ~2.5 days, all year around. Maybe less if not all files were old images, I didn't read the screenshots too closely.
I'm generally not even aware of the desktop background image (and thus never spend time to change it), it's always covered by actual application windows. Interesting.
macOS and 3rd party caches are out of control, so much so that I made an app for that about 12 years ago. It's freemium but the cache/3rd party quick clean is totally free and I don't really nag - https://www.iboostup.com or the App Store; unfortunately adware is becoming a problem on macOS too so it handles that as well. Users that opt in to stats have collectively freed petabytes of data. Requires El Cap or above, I update monthly so always supports the latest.
update: just released v10.5 that removes this huge wallpaper cache as part of Quick Clean, among other things. More info https://www.youtube.com/watch?v=H_M5GdnncxA - about to submit it to Apple.
> Apple’s storage prices are terribly high, the fuller a SSD is, the less it will last, why keep useless files
You knew you were buying soldered flash when you bought a modern Mac. If you want to save money, or heaven forbid, have a user serviceable laptop, the XPS 13 is one excellent option.
I think this would require a shift in mindset of programmers to change. As long as mantras like "space is cheap", "that memory would have been unused anyway" and "premature optimization is the root of all evil"* are frequently being passed on as good advice, we'll see stuff like this.
(* I know how the actual quote is meant, and there is a lot of truth to it: Micro-optimisations where the only practical reason is that the code invites you to do it are a bad idea. However in my experience, the quote is often misunderstood as arguing against any form of optimization. The quote is often used to justify code that's not just unoptimized but hilariously inefficient.)
My desktop background picture cache is 0GB. Perhaps I don't switch enough (mostly between one of the built-in ones or a solid color).
The most annoying caches are the ones generated by IDEs, they generally mix application-cache, plugin-cache and AST-cache all in one big cache so you don't really know if there is some huge Grails cache in there, if it's an old IDE version or if it's simple a runtime/electron/dotnet/java cache that got embedded with the rest. They are generally also either not versioned at all so not even the app would know what to nuke, and when they are versioned the old cache isn't getting wiped anymore because only the old version of the app would do that.
A OS-enforced cache would help, but then people would complain that they don't feel "in control"... (spoiler: unless you are an OS developer, it is highly unlikely that you ever really were in control, at most you might have had some feelings of control, or a measure of control that isn't realistic)
In one of those random coincidences, I recognize OP's username because just last night I was reading their forum comments on the OpenWRT forum about the Netgear WAX202. Was trying to decide if picking one up at a $30 sale price would make sense as a replacement for an older device, the R7800.
OP did not find it to be so after their testing, and as such, my $30 remained in my pocket.
Ahah yes, it’s me. Now the AX doesn’t work perfectly with OpenWrt but the devs are doing a great work and every day the support is going better. Anyway, also with the Negear firmware, the WAX202 has less coverage than the R7800 but if you’re near it, it’s faster of course.
Can someone explain why on earth a wallpaper cache is necessary for anything? Admittedly I just use whatever wallpaper comes with the current version of macOS and leave it for a year until the next version comes out. but even if I loved to change wallpaper two or three times a day, what would be the purpose of caching it?
I discovered these giant stupid wallpapers not to long ago when I was cleaning up my partners computer. They were taking up something like 20% of the total disc space on the machine, and there's absolutely no way to get rid of them. Very annoying!
OS-wide caching service when? Integrate automatic management of maximum cache size and we're done.
Having carte blanche access to $HOME -- or any other directory really -- should not be a given.
A lot of these problems can and should be fixed by OS services or, if these huge and wealthy companies can't be bothered, they can at least produce the interfaces/contracts and have other vendors implement them.
I honestly didn't expect that in 2022 we'll still be needing disk cleaners. It was somewhat expected back in 2002 but today... it's really shameful.
Probably similar things going in all the other Apple stack. I backed up my phone which was using around 110GB data. Restored it to a new phone and voila, it was using 70GB-ish after downloading all the apps again and syncing everything off iCloud.
Everything was intact, there wasn't anything like Music etc cached in that 110GB (I deleted all these beforehand), photos were still high resolution stored locally... everything was intact, with around 40GB less usage.
The (Apple) News App on macOS also uses a huge cache. I’ve seen it 5-10GB+. Without even using it regularly. I think to remove it I had to deselect it as an iCloud service in settings.
[+] [-] 323|3 years ago|reply
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.
[+] [-] ryandrake|3 years ago|reply
[+] [-] niknetniko|3 years ago|reply
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, ...)
[+] [-] cyberge99|3 years ago|reply
[+] [-] mcculley|3 years ago|reply
Likewise for system RAM. Lots of apps are using RAM to cache with no way to coordinate.
[+] [-] Derbasti|3 years ago|reply
Nevertheless, I soon stopped using Photos...
[+] [-] srvmshr|3 years ago|reply
[+] [-] anta40|3 years ago|reply
[+] [-] arve0|3 years ago|reply
[+] [-] smnscu|3 years ago|reply
[+] [-] ryandrake|3 years ago|reply
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.
[+] [-] least|3 years ago|reply
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.
[+] [-] greggsy|3 years ago|reply
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.
[+] [-] hcarvalhoalves|3 years ago|reply
[+] [-] kehrin|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] dimitar|3 years ago|reply
[+] [-] nicolas_t|3 years ago|reply
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.
[+] [-] haileys|3 years ago|reply
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.
[+] [-] addandsubtract|3 years ago|reply
[+] [-] userbinator|3 years ago|reply
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".
[+] [-] TillE|3 years ago|reply
[+] [-] conradfr|3 years ago|reply
Like why did we have it for cookies and not localstorage or Indexdb?
Is there any filesystem with ttl support?
[+] [-] oneplane|3 years ago|reply
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.
[+] [-] justinator|3 years ago|reply
Certainly isn't a ~/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop in my home.
[+] [-] ChrisMarshallNY|3 years ago|reply
I suspect it gets formed, when we use the Photos App to set the desktop.
I have always used the PrefPane.
[+] [-] pulvinar|3 years ago|reply
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.
[+] [-] Maursault|3 years ago|reply
> 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.
[+] [-] AceJohnny2|3 years ago|reply
(TBH I know nothing of how macOS implements its sandboxing system)
[+] [-] suction|3 years ago|reply
[deleted]
[+] [-] NobodyNada|3 years ago|reply
[1]: https://cdn.star.nesdis.noaa.gov/GOES16/ABI/CONUS/GEOCOLOR/l...
[+] [-] handedness|3 years ago|reply
[+] [-] indemnity|3 years ago|reply
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.
[+] [-] unwind|3 years ago|reply
But ... it boggles my mind how someone can change their wallpaper in my mind) 435 times in roughly 3 years. That's a new image every (365 * 3) / 435 = ~2.5 days, all year around. Maybe less if not all files were old images, I didn't read the screenshots too closely.
I'm generally not even aware of the desktop background image (and thus never spend time to change it), it's always covered by actual application windows. Interesting.
[+] [-] rolfrp|3 years ago|reply
[+] [-] rolfrp|3 years ago|reply
[+] [-] unethical_ban|3 years ago|reply
[+] [-] Hellion|3 years ago|reply
You knew you were buying soldered flash when you bought a modern Mac. If you want to save money, or heaven forbid, have a user serviceable laptop, the XPS 13 is one excellent option.
[+] [-] criddell|3 years ago|reply
[+] [-] xg15|3 years ago|reply
(* I know how the actual quote is meant, and there is a lot of truth to it: Micro-optimisations where the only practical reason is that the code invites you to do it are a bad idea. However in my experience, the quote is often misunderstood as arguing against any form of optimization. The quote is often used to justify code that's not just unoptimized but hilariously inefficient.)
[+] [-] oneplane|3 years ago|reply
The most annoying caches are the ones generated by IDEs, they generally mix application-cache, plugin-cache and AST-cache all in one big cache so you don't really know if there is some huge Grails cache in there, if it's an old IDE version or if it's simple a runtime/electron/dotnet/java cache that got embedded with the rest. They are generally also either not versioned at all so not even the app would know what to nuke, and when they are versioned the old cache isn't getting wiped anymore because only the old version of the app would do that.
A OS-enforced cache would help, but then people would complain that they don't feel "in control"... (spoiler: unless you are an OS developer, it is highly unlikely that you ever really were in control, at most you might have had some feelings of control, or a measure of control that isn't realistic)
[+] [-] Legion|3 years ago|reply
OP did not find it to be so after their testing, and as such, my $30 remained in my pocket.
[+] [-] giuliomagnifico|3 years ago|reply
[+] [-] tomcam|3 years ago|reply
[+] [-] wedn3sday|3 years ago|reply
[+] [-] pdimitar|3 years ago|reply
Having carte blanche access to $HOME -- or any other directory really -- should not be a given.
A lot of these problems can and should be fixed by OS services or, if these huge and wealthy companies can't be bothered, they can at least produce the interfaces/contracts and have other vendors implement them.
I honestly didn't expect that in 2022 we'll still be needing disk cleaners. It was somewhat expected back in 2002 but today... it's really shameful.
[+] [-] can16358p|3 years ago|reply
Everything was intact, there wasn't anything like Music etc cached in that 110GB (I deleted all these beforehand), photos were still high resolution stored locally... everything was intact, with around 40GB less usage.
Not surprised at this wallpapers cache at all.
[+] [-] sbr464|3 years ago|reply