Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Losing free disc space with hidden "Wallpaper.extension.image" generating many files when using your own photos for wallpaper on Sonoma

H

Hopefully

macrumors newbie
Original poster
May 10, 2023
6
2
I have noticed a new problem with the "extension-com.apple.wallpaper.extension.image" folder in the hidden folder (accessible by using Command-Shift-Period) called private -> var -> folders -> 64 -> C -> com.apple.wallpapers.caches continually generating and saving new files. There are (currently) about 47,000 files in each). This occurs on both a M1 Ultra Studio and a M1 Max PB Pro, both running Sonoma 14.0. It consumes (so far, it's constantly growing, about 2GB/hour) about 260 GB of space on each of the HDs. I have noticed the HD available space shrinking for about 3 (maybe about Oct. 1) days without any increase in the visible files. Emptying the trash or restarting the computer does not resolve the issue, and backups take forever and I usually give up on them because something is obviously wrong. There is not any purgeable space on Disc Utility. Nothing else seems to be wrong.

I had a bit of difficulty figuring out the screen savers and (especially) the wall paper settings in Sonoma. I have 2 (and occasionally 3) external monitors on the Studio, and the PB screen and 1-2 external monitors on the PB. On each of them I have the Wallpaper settings set to "Show on all spaces"-OFF, and I have chosen an external folder in my Pictures folder for the wallpaper. I use two different folders, one of them is on two monitors with 5 sec. intervals with the other with 1 minute intervals so that they are different, and the third monitor uses a separate folder of photos. Random and fill screen is checked for all of them. I don't use any of the apple provided screensavers.

The only other possibly related abnormality I've noticed is when waking up the studio, one or sometimes both of the monitors will jerk around for about a minute, mostly the icons and dock shrinking and expanding until it seems to find the right resolution. This occurred rarely on just the secondary monitor with the studio before Sonoma 14.0.

My questions:
1) Can I just delete the "extension-com.apple.wallpaper.extension.image" folder?
2) Anything else I could try - I haven't tried changing the wallpaper again because it was such a hassle to get it working; it seemed to take time to give you the options of specifying different monitor options and they didn't always seem consistent.
3) Any other recommendations?
4) Anybody else having this problem? I will also send in a bug report to apple.

Thank you for your help.
 
A quick follow up: I was able to delete the files in the "extension-com.apple.wallpaper.extension.image" folder, but they will repopulate again until you change the wallpaper. Apple provided screensavers don't seem to make files there. It will only make one (it initially makes two, but then deletes one of them) for each photo in your selected folder for the wallpapers. I had almost 47,000 photos in there, and it never caused a problem before, but with Sonoma it does. I made the folder smaller; with 1000 photos it builds up to about 4GB. I made 3 separate folders, one for each monitor so that there is more variety, but the hidden folder with png copies comes to about 12GB. So if you have a large folder of photos for your desktop and you're suddenly finding your free disc space declining, or your back-ups don't work, consider this as a possible cause of your problems. Screen savers seem to work fine.
 
Same here.

This bug or what ever it is use not only the original 14 GB for a bit over 10000 photos. This use in this folder again 130 GB for PNG files.

And when you remove photos in the original folder, it reduced not the photos in the big folder.

Why has apple made so a big error. For what? I see no reason for this.

No benefit etc. Only the SSD will destroy faster because the memory and much written things.
 
This is still unresolved as of the Sonoma 14.1 update. It still fills a folder called "extension-com.apple.wallpaper.extension.image", and could completely fill up your hard drive.

To find it, as outlined above, look in the hidden folder (accessible by using Command-Shift-Period) called private -> var -> folders -> and then a folder with a variable 2-character title which contains another folder with a lengthy-character folder inside of it, which has a folder "C" inside of it, usually overwhelming the largest of anything in the whole "folders". The "extension-com.apple.wallpaper.extension.image" is inside of that and may be the largest file on your computer by now. Sometimes it's easier to find the file sorting by size.

This folder will eventually grow to about 10x the size of the folder that you select for your desktop wallpaper photos, at least in my case. If you empty this folder, it will grow back again. The only resolution I have found is to make separate folders of the photos you want to use for the desktop wallpapers with a small number of photos in each one and select them in the system preferences. Don't forget to empty out the find the "extension-com.apple.wallpaper.extension.image" folder, since they don't seem to disappear if you select a new source folder, although it will fill up again with the same number of .png files as the number of photos in the folders you have selected for your desktop wallpapers. So try to keep the number of photos small and probably don't choose new folders very often.

I agree, I don't see any benefit to this and it can cause untold grief and difficulty for most users. Most people wouldn't have a clue where to find this folder, wouldn't know how to find a hidden folder, and like me would be hesitant to delete a system file without knowing what it was for. And it was so nice previously to be able to cycle through a large number of customized photos for desktop wallpapers. The lack of any warnings or instructions on this is incomprehensible as it can cause huge problems for many users.
 
It is really an impertinence on Apple's part what they are doing here.

That is not acceptable at all. What is this crap for? I haven't had any problems with it for over 10 years. Only now. And I don't understand the reason for it at all.
 
Since the files are in the Chach, and these are strangely not saved by the Timemachine, I did a test. I filled the SSD of the Mac to the maximum. I thought maybe it would then free up memory again. But unfortunately not. Everything in the large folder is supposed to be in there and uses up a lot of storage capacity unnecessarily. If Apple does not come up with a solution in time, I will buy other devices in the future.

I don't pay Apple a lot of money for a lot of memory so that Apple then uses it up unnecessarily with something like this.

Translated with DeepL
 
Yeah - I had continuously dwindling storage since I upgraded to Sonoma - took me until now to track it down - had ~170GB lost in that folder (which is of course not visible anywhere in finder and to spend a lot of time trying to track it down in the terminal) as I had a large photo library on a 1 minute slideshow - so every minute it would eat up ~10MB for a 4K png image. Not only is it not capping and cleaning up this cache stupid - the fact that it uses PNG format is horrible for photographic content (and that is what most wallpaper images tend to be)

What I've done - and seem to have fixed it for now (seems to at least survive reboot - not sure if it will survive an update) is go to the the parent directory of the "extension-com.apple.wallpaper.extension.image" (/System/Volumes/Data/private/var/folders/1f/51h8_q1j2mlbtpf06lz660n00000gn/C/com.apple.wallpaper.caches on my system although I expect those directories between "folders" and "C" may vary from system to system but I don't know) - completely delete that directory in the terminal using "rm -fr extension-com.apple.wallpaper.extension.image" and then quickly before it has a chance to recreate and start writing new ones out run "ln -s /dev/null extension-com.apple.wallpaper.extension.image" to symlink that directory to /dev/null so that it can't create any more.

Slideshow wallpaper is still working nicely and doesn't seem to be creating any issues.
 
  • Like
Reactions: ipaqrat
Uff wow. that I must translate step by step in my language, that I do nothing wrong.
But it is horrible that this is normal at Apple. I dont believe that Apple change this anymore.
So people must buy sooner there super expensive SSD Storage.

OK i have an 1 TB wo was 25 % Full. Now it is 39 % Full only because this issue.

But I am really unhappy about this.

I was aks that in the official Apple Support Forums. Because the SSD Life is with this faster comes to an end.
But they was delete my post.

But I have found out, that the PNG Files scales in the right size for the monitor you use. So a photo must not scales up or down every time. Maybe this is the reason. But why they made from a 4-5 MB big a right scaled 25-30 MB big PNG?

:-(
 
Last edited:
Yeah - this is a terrible bug for anyone using a slideshow wallpaper - not only eats up space (which is hard to find and delete if you don't know inner workings) but will also lessen SSD life.

My link to /dev/null trick seems to be holding up (at least went the full night without recreating anything) although don't know if it will be permanent.

I also filed a bug report through the developer portal feedback section - hopefully they take that more seriously as the apple support forums tend to be a joke and completely useless.
 
I delete after the last Updates 10 Wallpapers in the big folder. And than I wait. after some days they was all back again. :-(

Maybe the big December Update brings something new. But I dont believe.
 
I am sorry you are having this issue, what a mess. As a data point, I just checked an M3 and M2 MacBook Pro , and neither have this .image folder or a large disk size build up. Something must be causing it on some computers and not others? I used @Hopefully's instructions to check for it:

To find it, as outlined above, look in the hidden folder (accessible by using Command-Shift-Period) called private -> var -> folders -> and then a folder with a variable 2-character title which contains another folder with a lengthy-character folder inside of it, which has a folder "C" inside of it, usually overwhelming the largest of anything in the whole "folders". The "extension-com.apple.wallpaper.extension.image" is inside of that.

Through those instructions I easily found the "C" folder, but neither computer had the extension-com.apple.wallpaper.extension.image folder at all!

Let me know if you want me to check anything else to possibly narrow down what might be causing it, if you don't already know.
 
I have:

-> var -> folders -> 01 -> and then the long number... -> C -> com.apple.wallpaper.caches -> extension-com.apple.wallpaper.extension.image

​

 
jfx-2021 said:
I have:

-> var -> folders -> 01 -> and then the long number... -> C -> com.apple.wallpaper.caches -> extension-com.apple.wallpaper.extension.image

​

Click to expand...
I have something similar to that, but no .image file - I have a .video file, and it's only 21MB:
 

Attachments

  • Screenshot 2023-12-11 at 7.35.56 AM.png
    Screenshot 2023-12-11 at 7.35.56 AM.png
    271.8 KB · Views: 104
Hi, and how many personal photos u have in ur normal wallpaper folder? And u have setting, that every x.. change the wallpaper?
 
14.2 is the big December Update what I was mean is now available for download.

Will it change something in this case?
 
Nope. This 14.2 Update has not change anything. Again it copy and etc. in this folder.

Apple is really bad. Really.
 
This issue persists still. I use an app called Irvue to rotate my wallpaper every 30 minutes using images from Unsplash.com, which is what causes the images to populate the folder in the first place. But no idea why Apple isn't cleaning it up automatically like they did in versions of macOS previous to Sonoma.
 
Definately a rendering issue. The wallpaper applet takes the source image, and generates a new - uncompressed PNG version, which it uses for the actual display. On my system seems not to create a duplicate image every time a file comes up in rotation, but when the image is called to a different display. I routinely use three displays (MBP built-in, plus two different models of 27" in different locations).

I had three dupes of most images. Then I cleared the cache folder and watched the accumulation of new files AND the wallpaper changes on both displays for an hour (Yeah, I did that because science. You're welcome :cool: And also I didn't want to go out in the cold to feed the horses.). Now I have TWO of some image files that appeared on both displays, only ONE of other images that have not yet rotated to both displays.

For my 2019 Intel 15" MBP, I can tentatively conclude EDIT: stupidly, that it's neither random misfire, nor bug. Rather:
  • every permutation of File X Display gets a new PNG image file in the cache folder,
  • generated the first time the permutation is encountered.
  • It plateaus with a fixed, relatively static collection of wallpaper images.
  • It does not "Clean Up" the folder, because as far as it's concerned, nothing is discarded or aged out.
In my pics folder, all JPG, images run from 230 KB to 650 KB. Cached PNGs are 1.7 to 3.9 MB, implying decompression of the JPG, rather than some more elaborate upscaling for display resolution.

This behavior would positively HAMMER storage - seemingly at random, but it's not - when the slideshow image source was refreshed often, or was connected to an ephemeral source of constantly refreshed images (web service?). It would never plateau, and would always make uncompressed PNGs for each display any file was called up for.

Is it possible this is just a hair-splitting scheme to minimize power consumption? Simply opening a cached image file from the SSD should take less power than reprocessing/decompressing the source file every time it's needed, however miniscule that might seem. Maybe so it won't wake up rendering cores that might have been sleeping?

They would probably not make the software sense desktop vs. laptop, becuase that would be another lap through debugging, and they got deadlines, dammit. So the problem would appear on a Studio same as a MBP??

Perhaps older OSs didn't have the issue, or it wasn't as noticeable because the OS/Silicone wasn't quite so OCD about core power cycles? Giving them too much credit?

EDIT: I Reconsidered above ⬆️ conclusion, though observations remain valid. I think it is a bug, or bad design, after re-reading @marus25 . Below this point ⬇️, still probably correct...

The way Apple behaves lately, they prolly figure, "**** ya for not buying the $800 drive upgrade. Go ahead and worry yourself over your wallpaper cache."

Am I projecting my own grouchiness onto Apple because I chose horses who eat all my money before I can give it to Apple? 🐴 Herrrr yep!
 
Last edited:
I haven't tried yet, but perhaps there is a way to set up an Automator/Shortcut/AppleScript to automatically delete the contents of the com.apple.wallpaper.caches folder at specified intervals (such as daily at noon, or at login time, etc.).

This is obscene. I had 2 copies of wallpapers that aren't even on my system anymore dating back to mid-2023.
 
MacGizmo said:
I haven't tried yet, but perhaps there is a way to set up an Automator/Shortcut/AppleScript to automatically delete the contents of the com.apple.wallpaper.caches folder at specified intervals (such as daily at noon, or at login time, etc.).

This is obscene. I had 2 copies of wallpapers that aren't even on my system anymore dating back to mid-2023.
Click to expand...
Hypothetically, every wallpaper ever displayed, even momentarily, dating back to when this updated method was first introduced... will still be in that cache.

Today, having stood up and let the blood back into my brain, I reconsidered bug scenarios -- or a plain crappy redesign scenarios (which seems more likely because Apple these days) -- possibly related to how certain apps automatically save junk by default, and then force you click to DELETE it, if you didn't want to keep it?? The Preview App does this when you do a screen grab that way. TextEdit, too.

So, maybe the wallpaper slideshow app DOES reprocess the image from source, every time, and depends the cached file for only an instant, but is forced to save. However, the datetime stamps on cached files don't increment after initial caching. This implies that the app is forced to save, but does not overwrite, and obviously does not immediately delete its cache file.

This last hypothesis is supported by @marus25 symlinking the cache folder to /dev/null, essentially "disappearing" the decompressed file down the ol' memory hole. This would mean that the cache files are not, never were, reused by the wallpaper slidey app, and Apple's coding practice is as shoddy as recent consensus holds.
 
Delete the contents of your apple.wallpaper.caches folder.
Change the permissions of your apple.wallpaper.caches folder to read-only so that files cannot be written to it.
Lock the folder for good measure.
Monitor your disk space.
 
Ended up here after looking at a fairly random "what's up with disk usage" post on Reddit. Fortunately, I'm only using a total of 260 images for wallpaper on my 5 desktops, so disk usage wasn't horrendous.

Since nobody mentioned doing so in this thread, I filed a Feedback with Apple describing the issue - it's FB14279301.
 
I think this is fixed in Sequoia.

I'm running Sequoia Beta 3. Previous to this, I was running Sonoma.

I checked the file path and had about 10 GB of wallpapers cached. Deleted them, then started setting random wallpapers (both system defaults and my own images) and the folder did not repopulate. Even after a restart.

It is interesting to note that in Sequoia the wallpaper process is handled differently. I don't know the specifics, but there's more info in this tweet here:

https://twitter.com/x/status/1800882582361411707
 
  • Like
Reactions: rnb2
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back