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?
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?
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.
Similar assumptions about filesystems fail if they do data compression or dedupe files - you can easily overestimate how much space something is taking.
I find it so embarrassing because every dev gets fed this culture. Or take the insane update sizes. Os or Xcode. Or the upload to the app store useing bandwidth several times the binary size. An app that used to be .5MB in objc is now in swift 15MB tesflight, 70MB production ipa and 300MB upload traffic.
That's what sustainability looks like in the eyes of a hardware supplier.
Xcode is actually only about 17 GB on disk, assuming you haven’t copied it anywhere. When it’s installed transparent APFS compression is applied to the bundle.
I 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.
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.
> 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.
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.
That’s likely uncompressed. Try running du -h -d0 against it to see its on-disk usage. If it’s still high, you probably accidentally decompressed it and might benefit from a reinstall to fix that.
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.
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.
Symbolicating a crash report is annoying but mostly mechanical (fwiw you can open them in Xcode and it will pull in all the dSYMs for you). Reading a crash report is an art.
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.
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.
> I recently discovered a big cache - in terms of file number, 6000 files - of basically every edit I did in the last 6 months in VS Code - called Local History.
Isn't this a feature? I wouldn't want my editor to remove my local history without me knowing. I frequently use this local history (in Intellij), for whatever reason (it's easier than git, the project doesn't have version control, I haven't committed yet, ...)
6 months is a very long time for this though. I imagine that I would almost never want local history past a day or two. Beyond that I would look to my version control system.
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.
Yeah for sure, but this tool is really good for helping you visualize and discover what's eating up your storage, better than anything built in to any of the OSes that I use anyways.
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).
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.
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?
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.
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...
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.
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.
I take little issue with .DS_Store because it's located where you expect. What I do have an issue with, are cached files that hide in folders that are unknown to me.
I got a MacBook Air 2020 with 128GB storage to use mostly for browsing and light dev and that quickly filled up. It's like the OS tries to obsolete the machine as quickly as possible. The biggest annoyance is Finder telling me most of the storage is used by "Other".
The iPhone is doing the same. The unremovable caches will kill your space with time.
I remember the Apple Music app caching and never removing any songs you’ve listened to and not showing any space it uses in settings.
But this behavior is not specific to the Apple Music app - any other can do it too. Any caches from social apps you use have a high chance of being untraceable - it all goes into "Other".
Why? Try buying a model with a higher capacity to get an answer.
I also saw this behavior with an Android device - where removing a messenger on my grandfather’s phone freed up 20+ GB of space.
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'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.
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.
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.
> 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...
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.
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.
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.
As someone with a 128 GB model, I manage just fine. This is not the same as selling 16 GB models 3 or so years ago (that was ridiculous). It’s only a “scam” if you’re someone that needs more space and thinks having a “just fine” lower tier is a scam.
There's a useful Apple-created tool built right into the OS:
1. Cmd-space for Spotlight
2. Type Storage Management
3. Hit Review Files
Now you can sort by largest files and quickly make an impact on space used.
The only problem I had with Apple's storage management utility is that it kept reporting a Steam game using 27G when that game was long deleted (and Steam itself was deleted). To resolve this, I had to go to the ~/Library/Application Support directory and completely remove the Steam folder (which didn't actually have that 27G game anywhere in it.)
My longstanding favorite for this has been OmniDiskSweeper[0]. It's dead simple and I've been using it for just about the entirety of OS X's existence.
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.
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.
This scans the root filesystem but excludes the Volume mounts specifically (the -x option to limit the scan to the current filesystem doesn't work properly on mac os).
Navigate through the folders, sorted by size, from there. Press d to delete a folder.
It’s borderline criminal that these were sold with soldered-on SSD’s that can never be upgraded. It makes piles of otherwise completely useful laptops unusable pieces of shit. Same with the RAM.
The environmental damage alone that comes from this practice is heart wrenching. No possible performance benefits can be worth the damage it does.
“Other” is probably 90% from ~/Library/Application Support/. Because apps like Chrome are too lazy to split things out of there to make them legible to the OS — e.g. putting their cache dirs under ~/Library/Caches/, etc.
i'm amazed that they still sell/sold 128gb versions that late. I remember deciding never to get a computer with that small a hard drive again a bit less than 10 years ago. it clutters up so fast.
I've given up... Now I always order the 4TB option with any new mbp I order. Like this I never have to think about diskspace. I know for a fact that there's a lot of useless junk that I shouldn't need. I know that devs are lazy about cleaning up disk space and long are the days of my 120mb hard disk on my 486 but after struggling with disk space growing uncontrollably in a 1TB ssd, I just can't be bothered dealing with that.
By doing this, I'm part of the problem. By not establishing boundaries and refusing to install apps like Xcode that are programmed to put as much trash as possible, I contribute to making it acceptable for developers to treat us like this but it's a fight I'll admit I've lost.
I feel you. My macbooks have always reached the point of feeling very cramped for storage and I find myself juggling for disk space more often than I'd like. This is mostly because I simply won't pay an extra thousand dollars - what Apple charges for maxed storage in my currency.
I recently ordered a Framework laptop. It's yet to arrive, but I'm already excited about the fact that I could just order a very large, very fast, top of the line NVMe drive from a PC parts vendor for only a few hundred dollars.
Instead of getting a bigger internal disk, I opted for an external USB-C drive. The one I got (SanDisk Portable SSD) has 2TB of storage and transfers data at 1GB/s, so fast enough for everyday uses. I use it mostly for cold storage of larger files I rarely need and backups. So instead of spending $600 on the internal 2TB, my external drive only cost me $200 and is small enough to fit into any pocket.
I'm not by any means a regular user of macOS but whenever I've had to use it, it's had the impression of a sleek and elegant face with much worse below the surface, and this is no different.
It makes sense to make a copy when you set an image as a wallpaper, but what doesn't make sense is to keep that copy (with an automatically generated unique name!?!?) even after another wallpaper is set.
But, looking at the "wrong way" and guessing at the implementation, I have an idea how this happened: "Share" makes a copy with a unique name, presumably to avoid conflicting with anything else, and then tells the OS to set that as the wallpaper.
I wouldn't even call this a "cache", but a "leak".
Everything is a mess under the surface. It's more or less impossible to write something as complex as a modern desktop OS and keep all your code and behavior neat and tidy.
It's not really TTL that's needed here, it's a notion of file/directory tree priority integrated with the filing system APIs. Think about it: there's no reason not to use every single byte of your disk. The only reason we have to leave so much empty space as padding today and manage it so manually is because the OS itself won't automatically delete unimportant files when needed. If it did then apps could just generate caches with abandon safe in the knowledge that they'd be overwritten when necessary. Also, the user would always see the "true" amount of free space, i.e. actual space - caches - tmp files.
This is perfectly elegant. The desktop picture and the photos for it are segmented from the rest of the system in a container (similar to Virtual Locations on Windows) that the app can access instead of letting every random app access all your files at once without you having any control about it.
Regarding caching: generally, it's up to each individual developer (and sometimes even different teams within a company) to do this right. The only place where developers are 'forced' to do it right is '/tmp/' because that is supposed to get nuked every reboot.
that the app can access instead of letting every random app access all your files at once without you having any control about it.
That has nothing at all to do with this idiocy of using a different name every time, and not even thinking that it could be a problem to automatically create effectively "orphaned" files that no one would know about until it's too late.
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?
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.
The actual folder is "/System/Library/Desktop\ Pictures", but it's protected on newer systems. It consumes 414MB on my machine, which is 0.3% of a 128GB drive. Doesn't seem worth the trouble to me.
BTW, I found the path by double-clicking the folder as seen in Desktop & Screen Saver, then dragged that selected Finder folder to a terminal window.
No, this is the wallpapers folder used to store all the default macOS wallpapers, not a cache folder, don’t delete it (if you don’t want to delete all the macOS stock wallpapers).
>> The folder path is: Macintosh SSD > Users > [yourHome] > Library > Containers > Photos > Data > Library > Application Support > Photos Desktop
> The folder path is: Macintosh SSD/Users/[yourHome]/Library/Containers/Photos/Data/Library/Application Support/Photos Desktop
The $PATH is ~/Library/Containers/Photos/Data/Library/Application\ Support/Photos\ Desktop/
I have no idea what, if anything, is there, but this was bothering me. You almost had it, though, and I have no clue where the idea of using " > " as a $PATH separator came from, some kind of 1337 vppdpp h4x0r group maybe, but it's crazy.
Because it's a `Library/Application Support` folder within `~/Library/Containers/`, I wonder if this a feature hastily ported to macOS's sandboxing system.
(TBH I know nothing of how macOS implements its sandboxing system)
~/Library/Containers/* is where sandbox containers live. The folder structure within the container intentionally matches up with the folder structure non-sandboxed apps use, where the Data subfolder looks very similar to the user's home folder. I've never tested but I assume that sandboxed apps that call the macOS API that returns the user's home folder are actually given the path to their container's data folder instead. This makes it a lot easier to sandbox apps.
Ugh, I got bitten by this recently. I have a little program that downloads the latest satellite imagery from NOAA [1] and sets it as my desktop background every 5 minutes. One day I was wondering where the heck all my storage went...and found a 200GB wallpaper cache.
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.
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.
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.
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.
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.
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.
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.
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.
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.