macOS keeps a huge wallpapers cache(giuliomagnifico.blog)
giuliomagnifico.blog
macOS keeps a huge wallpapers cache
https://giuliomagnifico.blog/tips/2022/09/25/macos-wallpaper-huge-cache.html
209 comments
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 highly recommend the free app DevCleaner - https://apps.apple.com/us/app/devcleaner-for-xcode/id1388020...
I use it almost weekly to clear out the tens of gigabytes of garbage Xcode regularly generates.
I use it almost weekly to clear out the tens of gigabytes of garbage Xcode regularly generates.
Should not be necessary. It's just wrong to have a whole app dedicated to cleaning up after Apple's Lazy Ass.
It isn't necessary, caches are deleted automatically. You just don't have low enough disk space to need it deleted.
(This doesn't necessarily apply to apps who don't put things in Caches folders…)
(This doesn't necessarily apply to apps who don't put things in Caches folders…)
Except Xcode can't possibly know before hand when I do need the space back. Let's say I have 10GB free, so Xcode says "Well, you just don't have low enough disk space to need it deleted" while I'm trying to install Premiere Pro that requires 30GB of space (just an example), but I can't, because I don't have enough disk space.
How about not trying to guess when the user needs the space?
How about not trying to guess when the user needs the space?
This is the same problem I have with the "unused RAM is wasted RAM" argument. So long as a system has a maximum of one application using this strategy, it works. As soon as you have two independent programs each of which try to cache as much as possible, it falls apart.
For a while, the browser could reasonably assume that it was the only application that used this strategy, and it was a true assumption. Now that native executables are being replaced by web-based applications, every program is trying to maximize its RAM usage, with predictable results.
For a while, the browser could reasonably assume that it was the only application that used this strategy, and it was a true assumption. Now that native executables are being replaced by web-based applications, every program is trying to maximize its RAM usage, with predictable results.
It works fine if they tell the VM that its cache regions are purgeable, so they just go away under pressure instead of getting swapped out.
Of course getting swapped out is usually fine too.
Huge memory usage is more likely because they don’t know how to check for memory leaks, not because they’re trying to use it.
Of course getting swapped out is usually fine too.
Huge memory usage is more likely because they don’t know how to check for memory leaks, not because they’re trying to use it.
How’s the “I can’t” work? If the installer is telling you it can’t that just means it’s checking for free disk space the wrong way.
The fact there’s a right way and wrong way to check free disk space is a problem in the first place.
Pretty classic problem.
https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
Similar assumptions about filesystems fail if they do data compression or dedupe files - you can easily overestimate how much space something is taking.
https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use
Similar assumptions about filesystems fail if they do data compression or dedupe files - you can easily overestimate how much space something is taking.
Ah. Ok that makes more sense.
There is a tool in the MacOS that will find large sized apps and allow you to delete them.
But we already know what the large tool is, and it can be a dependency for other languages when using natively compiled libraries.
What is the tool ?
Apple has added a thing in Ventura (?) to list and let you remove these files.
Does it have a name?
Apple Menu > About This Mac > Storage > (Volume Name) > [Manage...]
I don't know the name, but IIRC it's something like "disk usage". It resembles roughly the "storage" panel on iOS.
On macOS 12 it's part of the System Information app at least and called "Storage Management"
I'm pretty sure it was there before, my 2013 mbp is too old to run the latest version, and I've seen it there, too.
Holy crap. Thank you for that pointer and my 92GBs of newly free space.
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.
That's what sustainability looks like in the eyes of a hardware supplier.
OmniDiskSweeper is free: https://www.omnigroup.com/more
So is GrandPerspective: http://grandperspectiv.sourceforge.net
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.
"Only 17GB"
Lol.
Lol.
It’s down to 11 with Xcode 14 ;)
I know right? It’s only multiple OSs, multiple simulators, duplicated binaries for them all. Totally unreasonable for it to be 17gig! After all chrome manages to fit in only half a gig, and it has like a whole browser.
Who needs it all? Don't force on me what I don't need as once was and alas is no more.
It's all there because the usability is much better if you download one thing, and then no matter what you then choose to work on, it's available.
That said, I think that code signature on Xcode does let you delete whichever sdks and simulators you want without invalidating the main package signature? (This is _very_ much an "I think" case). That would remove the "force" element you find to be a problem.
That said, I think that code signature on Xcode does let you delete whichever sdks and simulators you want without invalidating the main package signature? (This is _very_ much an "I think" case). That would remove the "force" element you find to be a problem.
> usability is much better
of the download/onboarding! Which is not what I should spend most my time with Xcode anyway.
I would eagerly spend 5 minutes more choosing if I could reduce the several hours (sic!) download time and save insane amounts of energy.
of the download/onboarding! Which is not what I should spend most my time with Xcode anyway.
I would eagerly spend 5 minutes more choosing if I could reduce the several hours (sic!) download time and save insane amounts of energy.
> of the download/onboarding! Which is not what I should spend most my time with Xcode anyway.
No, of the runtime use. There is no need to have a up front "what hardware are you planning to target?" "what OS versions are you planning to target?".
The several hour download when high speed internet is not available is obviously annoying, but it is not remotely "insane amounts of energy".
But on the other hand you don't get in a position where you think you've made the correct selection, and then a little bit later you go to do something and can't, so have to wait on another download, right when you were wanting to do something.
The approach of "everything in one bundle" is the correct option from a usability point of view, which is clearly what has been favored. It is also clearly and reasonably frustrating that that one download is large and on slower connections is very long. The thing is that the single download means that the install path is "set it to download; go to bed; get up and use freshly downloaded gigantic bundle" with no risk of thinking your done, but then not having everything you need. I suspect the latter would result in many more people complaining on twitter, or needing support.
I do want to be clear though that I agree the large download is annoying, and surely something could be done to reduce the size.
No, of the runtime use. There is no need to have a up front "what hardware are you planning to target?" "what OS versions are you planning to target?".
The several hour download when high speed internet is not available is obviously annoying, but it is not remotely "insane amounts of energy".
But on the other hand you don't get in a position where you think you've made the correct selection, and then a little bit later you go to do something and can't, so have to wait on another download, right when you were wanting to do something.
The approach of "everything in one bundle" is the correct option from a usability point of view, which is clearly what has been favored. It is also clearly and reasonably frustrating that that one download is large and on slower connections is very long. The thing is that the single download means that the install path is "set it to download; go to bed; get up and use freshly downloaded gigantic bundle" with no risk of thinking your done, but then not having everything you need. I suspect the latter would result in many more people complaining on twitter, or needing support.
I do want to be clear though that I agree the large download is annoying, and surely something could be done to reduce the size.
[deleted]
[deleted]
I assume you are referring to Xcode's on disk size on Apple Silicon because I downloaded Xcode 14.0.1 yesterday (a 7.6 GB download) which expanded to 23.01 GB on disk. This is on a MBP with an Intel chip.
I have a sidebar alias to my DerivedData directory (and I have Xcode set up to use it for everything).
I'll flush it, from time to time. I may also delete old archives. I have hundreds of them.
I'll flush it, from time to time. I may also delete old archives. I have hundreds of them.
I would recommend being cautious about clearing old archives, as they will have symbols to help you analyze crash reports and such.
Good point. I tend to keep the last month of releases, and whatever is currently on the store.
I find those symbols to be kinda worthless, though.
My best tool for diagnosing a crash report is a Ouija board.
I find those symbols to be kinda worthless, though.
My best tool for diagnosing a crash report is a Ouija board.
Symbols are a godsend when dealing with difficult crash reports. Have you ever tried walking through the process of analyzing one with an expert? It's a great way to level up your diagnosis skills.
That’s a good suggestion.
Frankly, it’s not been much of an issue. I tend to be super-anal about Quality, and post-release crashes are rare as hen’s teeth; which makes the ones that do happen, more important to diagnose.
I usually get a general idea of where the crash happens, and scanning the source, has always shown me the issue.
Frankly, it’s not been much of an issue. I tend to be super-anal about Quality, and post-release crashes are rare as hen’s teeth; which makes the ones that do happen, more important to diagnose.
I usually get a general idea of where the crash happens, and scanning the source, has always shown me the issue.
You probably know this, but relying on your local machine and storage for this is a bad idea for production apps.
There are a ton of services that handle all the “mechanical” stuff for you (e.g. AppCenter, ex-HockeyApp), and you can just look at symbolicated crash in your browser.
There are a ton of services that handle all the “mechanical” stuff for you (e.g. AppCenter, ex-HockeyApp), and you can just look at symbolicated crash in your browser.
For production apps I would centralize symbols, yes. But I have a strong disdain for crash reporting services, which are typically authored by people who are designing for aggregating crashes and showing pretty charts rather than really getting deep into the actual log itself. Most have pitifully less information than an actual crash log would–often missing thread state, exception codes, and memory mappings.
[deleted]
> 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, ...)
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.
Of course if the data is small why not keep it.
Of course if the data is small why not keep it.
I do think there should be a default expiry but I’ve absolutely went back many many months and found old versions of files in cases I didn’t have proper commits.
Check out DaisyDisk. It shows how much space is “purgable” (cache files like this, etc).
I love DaisyDisk. Easily one of my top 20 apps of all time.
I agree! It's worth paying for for the time and the disk space it helps you save. Beautiful visual and UX design.
Disk Inventory X is a nagware alternative: http://derlien.com .
Grandperspective has the same look as disk inventory x but I found it to be significantly faster.
I haven’t noticed any nag screens but I didn’t when using disk inventory x either so I might just be immune to them.
https://grandperspectiv.sourceforge.net/
I haven’t noticed any nag screens but I didn’t when using disk inventory x either so I might just be immune to them.
https://grandperspectiv.sourceforge.net/
You can also buy Grandperspective from the app store for a few dollars to help support the overall development.
Or Filelight, which is free! https://apps.kde.org/filelight/
only Linux and Windows.
The source is available (https://invent.kde.org/utilities/filelight), and there's a chance it'll build on macOS. I haven't tried, though (and am not the original recommender).
No reason it shouldn't work on MacOS, a lot of KDE/Qt projects compile fine without any additional changes.
But yes, if you're on Mac it's probably easier to buy Daisy Disk.
But yes, if you're on Mac it's probably easier to buy Daisy Disk.
[deleted]
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.
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.
Nevertheless, I soon stopped using Photos...
Nevertheless, I soon stopped using Photos...
I was looking for previous installed versions of VSCode. Any pointers where did you find them in your `~/Library/`
True:
Whatsapp, MS Teams, Android Studio, Homebrew, etc.
Really pain in the a*ss if you're on 128 GB Mac.
The history feature in VSCode have saved me multiple times. To me, 200MB per workspace is worth it.
Are you not using Git/any SCM or what?
They don't do anything automatically. VSCodes feature does keep every saved state of every file
Of course not. But why would I need "every saved state of every file"? The number of times that would have saved me would be zero, because I never ended up in a case where that would have saved me. Things I need saved are saved as stashes/things put in git, and the rest are things I don't need saved.
What scenarios are there where things like this would have saved me somehow?
What scenarios are there where things like this would have saved me somehow?
That vscode cache saved my ass at least once, when I deleted uncommitted changes accidentally.
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.
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.
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.
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.
To disable .DS_Store files:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true…of course, only on external disks.
Are internal disks likely to use a non-mac-native filesystem?
It's annoying for backing up directories or sharing directories between systems...
Then they would be external and the above solution would work?
No...
Use case is taking a copy (via say tar) of a directory hierarchy on a MacOS drive, and copying that to another system (Linux), and untarring... then you've got all the .DS_store files everywhere...
Not the end of the world, but annoying...
Use case is taking a copy (via say tar) of a directory hierarchy on a MacOS drive, and copying that to another system (Linux), and untarring... then you've got all the .DS_store files everywhere...
Not the end of the world, but annoying...
find . -type f -name .DS_Store -delete
I tend to do rm **/.DS_Store . I know it’s slow when there are lots of files, but it is still quicker than opening a man page or Stack Overflow to figure out what the hell the syntax is to do it with find.
Is that a meme like with `tar`?
Are there any downsides to doing this?
Downsides are if you access the network shares with finder it won’t maintain any appearance settings or where folders and files are “physically” placed.
[deleted]
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.
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.
The worst was podcasts. If you played a podcast without downloading it first, the entire thing would be cached forever.
I learned that the hard way after a NY to Miami road trip when I binged “Hardcore History”
I learned that the hard way after a NY to Miami road trip when I binged “Hardcore History”
I once found 15gb+ of Spotify cache from my 256gb MacBook. Deleted the app and use the web player now.
The cache is there for your benefit (and theirs too), so that you don't have to constantly re-download the same song over and over, which matters to some people that have bandwidth restrictions. There's a button in their settings that lets you clear it with ease
It doesn’t benefit me much as I have unlimited bandwidth and I can download an entire song in 10 seconds so don’t have any buffering.
I can see how it saves Spotify some bandwidth costs.
But I hate big caches as I don’t really think about them until my disk is full and I need to do something.
I wish programs would be better stewards of user resources.
I can see how it saves Spotify some bandwidth costs.
But I hate big caches as I don’t really think about them until my disk is full and I need to do something.
I wish programs would be better stewards of user resources.
I’ve had my music cached locally since the 90s.
People ask why everything is web apps and there's the answer - It's a layer of sandboxing that users have _at least some_ control over.
I feel like I'd have a better chance clearing the cache for the app than the cache for the web app.
It's a few clicks in any browsers dev tools or a few more clicks in the settings, and is the same for every website.
With a native app the cache could be in any number of places on your hard drive, you have to depend on a function being in the app to clear it, deleting it manually might have unknown side effects, and it's all nonstandard.
With a native app the cache could be in any number of places on your hard drive, you have to depend on a function being in the app to clear it, deleting it manually might have unknown side effects, and it's all nonstandard.
Websites can’t write to arbitrary places on your FS and the browser has a central way to delete the data that a website can write.
Desktop apps can write anywhere, and what it writes might or might not be a cache, so there’s no way to centrally manage it. Apps like cache-cleaners simply hard-code common cache paths for common apps.
Desktop apps can write anywhere, and what it writes might or might not be a cache, so there’s no way to centrally manage it. Apps like cache-cleaners simply hard-code common cache paths for common apps.
Teams web version has local storage of 2gb.
The problem is developers don’t know what the hell they’re doing
The problem is developers don’t know what the hell they’re doing
The problem is devs have beefy computers with 2TB SSDs.
In music, producers would listen to their mix on different audio systems, including crappy radios.
[deleted]
Not just the producers, but musicians often do this as well (the good ones anyway!)
Eh? People have some control over native apps too. It’s just a trade-off of what you want to control. I like how I can control the time I spend in my workflow just because native apps are faster and more battery-efficient, and don’t override OS gestures and mouse events within their own windows.
The problem with the web player is that the volume normalization feature is missing.
> 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...
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...
At least with iOS 16 this isn't an issue, not sure about prior versions. In Settings for Apple Music, it shows you a list of all artists, inside their listing is the albums, and inside there the songs you have downloaded. You can delete at each level (artist, album, or individual song). But it definitely removes items from the cache or, yeah, I'd have been out of storage a long time ago.
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.
If you have the 256gb model you’re not affected, but there are lots of devices out there with between 8 and 64gb of storage.
That doesn't really line up with the comment I replied to. It suggests that over time, space usage will continue to grow as part of some kind of planned obsolescence. That's the premise I was questioning.
None of the 128GB range were viable in the slightest.
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.
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.
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.
Not for most. I used a 16 GB iPhone SE with only a handful of apps for a while, but the biggest problem was the NY Times app where I get my news. Its cache will grow without bound, and once it would get to ~2 GB every few weeks I'd have to uninstall and reinstall the app to delete the cache. (Later on they created an option in settings to delete the cache.)
I thought the 16 GB phone would work for me since I keep everything in the cloud -- no downloaded photos/music/nothing. Nope, and it was all because of app caches. I got so sick of having to uninstall and reinstall some app literally every week to clear its cache.
I thought the 16 GB phone would work for me since I keep everything in the cloud -- no downloaded photos/music/nothing. Nope, and it was all because of app caches. I got so sick of having to uninstall and reinstall some app literally every week to clear its cache.
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 are two kinds of people who don't need a lot of disk space on their laptop:
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. 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?
It’s all down to your use case. I get by with a 16gb iPhone fine and have a 128gb MBA with have the space free.
Try something like disk inventory X. It's a life saver.
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.)
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.
[0]: https://www.omnigroup.com/more/
[0]: https://www.omnigroup.com/more/
Gotta put a word in for daisy disk! Maybe you're paying for some fancy animations, but by golly are they nice LOL.
I second Daisy Disk. When I made the leap from Windows to mac in the early 00s I wanted something to replace the freeware “scanner” I had found so entirely useful.
http://www.steffengerlach.de/freeware/
http://www.steffengerlach.de/freeware/
What’s the advantage of Daisy Disk over the built-in “About this Mac -> Storage -> Manage”? Always interested in lovely boutique MacOS software, but in this case the website doesn’t sell it well as an alternative to what’s already available.
Some of the best functional data vis out there. For those wondering the chart type used by daisy disk is called a zoomable sunburst.
DaisyDisk is great. Best $10 on an app I've ever spent (circa 2015)
Put my vote in for `ncdu` (just skip your iCloud folders)
I agree, ncdu is a great and easy to use command line tool.
On Mac OS, run for example:
On Mac OS, run for example:
ncdu -x --exclude /Volumes --exclude /System/Volumes /
Oh wow thank you
Disk Inventory X is great and that's how I found out the speech folder on my OS X was taking like 12GB.
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.
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.
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.
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".
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.
Maybe more things should have TTL capability in computing.
Like why did we have it for cookies and not localstorage or Indexdb?
Is there any filesystem with ttl support?
Like why did we have it for cookies and not localstorage or Indexdb?
Is there any filesystem with ttl support?
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.
compost!
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/...
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/...
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.
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.
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.
It has everything to do with using a different name every time. Say you have incompatible caches, do you really want to deny your user the option to run two versions in parallel?
> The folder path is: Macintosh SSD/Users/[yourHome]/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop
Certainly isn't a ~/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop in my home.
Certainly isn't a ~/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop in my home.
I don't have one, either.
I suspect it gets formed, when we use the Photos App to set the desktop.
I have always used the PrefPane.
I suspect it gets formed, when we use the Photos App to set the desktop.
I have always used the PrefPane.
Yes if you don’t use Photos to set the wallpapers, then you don’t have it.
Post should probably be titled "macOS Photos keeps a huge wallpapers cache", since it's not actually tied to the macOS wallpaper mechanism.
Yes maybe but Photos only creates a copy of the file/image in order to be used from macOS (due to Sandboxing). So it's more a macOS connected to Photos feature than Photos alone.
...in the end, it's just a mess.
...in the end, it's just a mess.
That explains it.
Also, the path that I have is as follows.
Also, the path that I have is as follows.
~/Library/Containers/com.apple.Photos/Data
Correct, mine is few MB (now). Just don't set the wallpapers via Photos in the future, or remember to clean this folder.
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.
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.
> "/System/Library/Desktop\ Pictures"
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).
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).
Sorry, I misread that.
That’s the desktop pictures folder. This is talking about some sort of cache for photos you use as your wallpaper.
>> 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.
> 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)
(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.
[1]: https://cdn.star.nesdis.noaa.gov/GOES16/ABI/CONUS/GEOCOLOR/l...
[1]: https://cdn.star.nesdis.noaa.gov/GOES16/ABI/CONUS/GEOCOLOR/l...
Out of curiosity, how do you have it set up? I've done something similar via cron and Automator, but it's pretty kludgy.
Mine’s also a little kludgy, it’s a like 50-line Swift menu bar app. The cron job is a good idea; it’s probably a little cleaner.
That's cool.
One would think mine's cleaner, but it's got its own problems involving it not recognizing a new image as different if the filename is unchanged, and even if I do staggered updates the only way to reliably make sure it takes every single time is to quit the Finder, which I of course refuse to do. It will, at times, decide it doesn't want to take for hours on end, with an image that updates every ~10-15 minutes, and then will later decide to start updating again, with no other state change having apparently happened to instigate it (e.g., rebooting, logging the session out, etc.).
It may just be my experience, but over time macOS is behaving more and more irregularly in more and more ways, for completely inscrutable reasons.
One would think mine's cleaner, but it's got its own problems involving it not recognizing a new image as different if the filename is unchanged, and even if I do staggered updates the only way to reliably make sure it takes every single time is to quit the Finder, which I of course refuse to do. It will, at times, decide it doesn't want to take for hours on end, with an image that updates every ~10-15 minutes, and then will later decide to start updating again, with no other state change having apparently happened to instigate it (e.g., rebooting, logging the session out, etc.).
It may just be my experience, but over time macOS is behaving more and more irregularly in more and more ways, for completely inscrutable reasons.
And yet, it cannot for the life of it preserve the wallpaper selection.
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.
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.
Wow, I can understand why that feels wasteful.
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.
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.
Yes usually I don’t change the wallpaper every 2/3 days but I download 10/20 photos and I try to set each as a wallpaper. This one/two time per month about so the average is correct.
[deleted]
Automatic daily wallpapers.
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.
Been in review for a few days, hopefully approved by Apple soon. Already available on www.iboostup.com
Update approved and now also live on the AppStore https://apps.apple.com/au/app/iboostup/id484829041?mt=12
"Delete cached wallpapers" should be art of a disk cleanup wizard, but I understand why they do it.
> 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.
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.)
(* 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)
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.
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.
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.
Not surprised at this wallpapers cache at all.
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.
Yes, on the iPhone is even more subtle because you can’t have access to the folders inside the filesystem.
Anyway I’m using less than 50GB on my iPhone, is hard to keep the space low because you have to check lots of things. For example I had almost 1GB of Health data that were steps and other things from years ago but I wasn’t able to free this space also after that I deleted all the records inside the Health app.
Finally I discovered that these data were from Apple Watch cached data, I had to disable the health app on the Apple Watch and then I went able to retrieve back my GB (3/4) of cache.
In this situation the records were useful (if you need it) but it was very difficult to find how to clear this space if you don’t want all these data. I’ve never thought that were data from Apple Watch stored inside the “other space” on the iPhone. At least not some GB.
Anyway I’m using less than 50GB on my iPhone, is hard to keep the space low because you have to check lots of things. For example I had almost 1GB of Health data that were steps and other things from years ago but I wasn’t able to free this space also after that I deleted all the records inside the Health app.
Finally I discovered that these data were from Apple Watch cached data, I had to disable the health app on the Apple Watch and then I went able to retrieve back my GB (3/4) of cache.
In this situation the records were useful (if you need it) but it was very difficult to find how to clear this space if you don’t want all these data. I’ve never thought that were data from Apple Watch stored inside the “other space” on the iPhone. At least not some GB.
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.
By the way, one easy way to find what’s taking up space in your Mac, using finder, is enable “Show View Options" in the "View" menu and choosing "Calculate all sizes", you can set to default to that if you want as well.
Then using list view you can sort all folders by size. It takes a while to calculate of course, faster with an SSD.
Then using list view you can sort all folders by size. It takes a while to calculate of course, faster with an SSD.
I left Serato indexing music overnight and it created a 300gb cache. Which was actually impressive tbh.
Are these cached files marked as purgeable? If they are, then what's the big deal?
If it was marked as purgeable, since the 2019 it should have been purged. Instead the folder is still here and keeps growing.
Assuming that they are purgeable (which I would guess they aren't) purging doesn't happen by date, it happens when disk space is needed. The whole point of purgeable storage is to keep stuff around where having it persist improves the user experience, but if necessary it can be reconstructed. Simply evicting anything older than X isn't particularly sensible if there isn't any pressure on diskspace.
The same thing generally happens for purgeable memory - if there isn't memory or battery life pressure there's no reason to evict anything.
The same thing generally happens for purgeable memory - if there isn't memory or battery life pressure there's no reason to evict anything.
I know how the cache works, your point is perfectly correct BUT this folder is not exactly a cache folder, due to Sandboxing of macOS this folder is where macOS stores a copy (creates a new file/photo) in oder to be used as a wallpaper from the other macOS resources.
If you set 123.jpg as a wallpaper today, you change it tomorrow with 321.jpg and you will set again 123.jpg in "x" time (few days), then macOS will not use again the file created with 123.jpg but it will create a new folder with the same wallpaper. As the cache should work.
This is just a pointless behavior of macOS, for semplicity I haven't write it on the post but maybe I should add this... If it was a cache folder, a really cache -useful- folder I wouldn't have said to delete it.
If you set 123.jpg as a wallpaper today, you change it tomorrow with 321.jpg and you will set again 123.jpg in "x" time (few days), then macOS will not use again the file created with 123.jpg but it will create a new folder with the same wallpaper. As the cache should work.
This is just a pointless behavior of macOS, for semplicity I haven't write it on the post but maybe I should add this... If it was a cache folder, a really cache -useful- folder I wouldn't have said to delete it.
In Ventura you have to click to download most wallpaper options, so they must have recognized the issue.
Unfortunately no, the Ventura behavior is another thing, you simply have to download the image to use it as a wallpaper (in order to don't have a huge folder in "/System/Library/Desktop\ Pictures" .
I don't know if macOS Ventura fixes this behavior of Photos, I'll try when it will be out of beta.
I don't know if macOS Ventura fixes this behavior of Photos, I'll try when it will be out of beta.
ncdu
I am using brew for installation.
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.