macOS keeps a huge wallpapers cache
giuliomagnifico.blog
giuliomagnifico.blog
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.
But yes, if you're on Mac it's probably easier to buy Daisy Disk.
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.
They've been maintaining that little app for a long time.
I'll flush it, from time to time. I may also delete old archives. I have hundreds of them.
I find those symbols to be kinda worthless, though.
My best tool for diagnosing a crash report is a Ouija board.
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.
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.
I use it almost weekly to clear out the tens of gigabytes of garbage Xcode regularly generates.
(This doesn't necessarily apply to apps who don't put things in Caches folders…)
How about not trying to guess when the user needs the space?
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.
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.
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.
Lol.
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.
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.
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.
du -h -d0 Xcode.app
12G Xcode.appThat's what sustainability looks like in the eyes of a hardware supplier.
Nevertheless, I soon stopped using Photos...
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.
What scenarios are there where things like this would have saved me somehow?
Likewise for system RAM. Lots of apps are using RAM to cache with no way to coordinate.
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.
defaults write com.apple.desktopservices DSDontWriteNetworkStores trueUse 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...
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.
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.
On Mac OS, run for example:
ncdu -x --exclude /Volumes --exclude /System/Volumes /
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.)
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 problem is developers don’t know what the hell they’re doing
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.
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.
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.
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...
I learned that the hard way after a NY to Miami road trip when I binged “Hardcore History”
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.
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.
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?
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".
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.
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/...
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.
Also, the path that I have is as follows.
~/Library/Containers/com.apple.Photos/Data
...in the end, it's just a mess.
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).
(TBH I know nothing of how macOS implements its sandboxing system)
> 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.
[1]: https://cdn.star.nesdis.noaa.gov/GOES16/ABI/CONUS/GEOCOLOR/l...
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.
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.
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.
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 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.)
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)
OP did not find it to be so after their testing, and as such, my $30 remained in my pocket.
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.
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.
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.
Then using list view you can sort all folders by size. It takes a while to calculate of course, faster with an SSD.
The same thing generally happens for purgeable memory - if there isn't memory or battery life pressure there's no reason to evict anything.
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.
I don't know if macOS Ventura fixes this behavior of Photos, I'll try when it will be out of beta.