I appreciate very much those insights into the inner workings of the defaults system.
I know from observation that the defaults read com.apple.desktop command in my shell script does return up-to-date desktop image data, but only if the Dock is rebooted by killing it. From your explanation of the intermediate defaults process to which the defaults read command is presumably talking, it would seem that defaults read should give me up-to-date data without any external interventions, and yet it doesn’t. Why isn’t it returning up-to-date data?
I’m not sure. It may something to do with the app and defaults having access to different domains, or there may be some quarantining to stop defaults-written values being used by a running app.
“At runtime, you use an NSUserDefaults object to read the defaults that your application uses from a user’s defaults database. NSUserDefaults caches the information to avoid having to open the user’s defaults database each time you need a default value. The synchronize method, which is automatically invoked at periodic intervals, keeps the in-memory cache in sync with a user’s defaults database.”
Sorry for any misleading information. I don’t actually recall saying it. The only post of mine I can find here containing ‘killall Dock’ is one from three years ago where I used it to update the Dock from the plist file, not vice versa. It was common practice at the time to kill a process after modifying its plist file so that it (the process) would adopt the changes when it restarted. It worked with that particular script in Snow Leopard, but I’ve not had enough time to fool around with it in Mavericks.
Nigel, sorry for the incorrect reference! I had flipped it around in my mind.
Shane, In concert with your description of the defaults system, I’ve noticed that NSUserDefaults’s standardUserDefaults object is always immediately up to date within a running application. It behaves just like an NSDictionary (perhaps it is a dictionary?) The caching problem seems to arise when an outside application wants to access the standardUserDefaults object’s data.
Would that not suggest that the defaults read command does not get direct access to the standardUserDefaults object but rather to the synched data that standardUserDefaults writes sporadically?
One of the thing people testing sandboxed apps used to do was kill their prefs plist files to reset things. When Mavericks came out, they were told not to do this, because the stuff might not be written to disk as promptly as before. There was also a hint of surprise that this was happening, so it wouldn’t be unexpected if the system was, or even has been already, tweaked some more.
All of which means you probably shouldn’t assume the results under one OS will match those on other versions.
Is this is an intentional effort to keep an application’s defaults data out of the reach of other applications or simply a side-effect of the way the system is being implemented?
I suspect the latter, although that’s just a guess. There are ways sandboxed apps can share prefs, even on iOS. I think the problem they were trying to address was performance, and trying to improve it by hitting the disk less often.
I wanted to share some info since this thread helped me. The code to get the path to the current desktop picture in Mavericks when you have it set to change at an interval is inspired. I couldn’t figure it out in Mavericks so thanks everyone.
Anyway, I also wanted to know how I could be automatically notified when the desktop picture changes. I figured out that you can watch a certain folder for changes because changes in that folder correspond to the desktop picture being changed. That folder is ~/Library/Application Support/Dock. It seems there’s some database files in there and one of those files is being updated when the desktop pic changes.
So now I’ve setup a launch agent to watch that folder and run an applescript when something in that folder changes. It’s working perfectly in sync as the desktop changes.
I hope this helps someone else as much as the applescript code to find the current desktop picture has helped me.
NOTE: I tried briefly to read the db files in the Dock folder because they must hold the path to the desktop picture… but I wasn’t able to access it. Maybe someone else will have better luck. Please post how you did it if anyone figures it out.
I have a folder with 3000 images that contain all my desktop images, I’ve set them to rotate every 15 minutes. Sometimes I want to identify the file name of the current desktop image so I can delete it or identify it as a favorite.
Does anyone have an apple script that will find the location of the current desktop image in OS X Yosemite (10.10)? All the solutions I’ve found in forums only apply for earlier (sometimes much earlier) operating systems.
I realize this is a very old thread, but I had a script working perfectly (based on Nigel Garvey’s) to display the name and path of the current desktop image under several MacOS versions…until Big Sur. Now, the script result is correctly identifying the path, but not the correct image file. The heart of the script is
To identify the current image folder:
tell application “System Events” to set pFldr to pictures folder of current desktop
To identify the current image name:
set picturePath to pFldr & “/” & paragraph 1 of (do shell script "ls -tu " & quoted form of pFldr)
I’m definitely not anything approaching an expert, but pFldr is still providing the correct folder name.
As best as I can tell, the “ls -tu” command is no longer returning the correct file name, but I don’t know why. Did the bash shell change or did the MacOS behavior change with 11.6?
Any solution? I’d appreciate hearing from anyone more knowledgeable than me (which is pretty much everyone). TIA!