Re: error attempting AppleShowAllFiles
Re: error attempting AppleShowAllFiles
- Subject: Re: error attempting AppleShowAllFiles
- From: Ron Hunsinger <email@hidden>
- Date: Fri, 21 Oct 2011 23:48:30 -0700
On Oct 21, 2011, at 6:57 PM, John Baltutis wrote:
> On 10/21/11, Ron Hunsinger <email@hidden> wrote:
>>
>> There is a more subtle bug in the script you supply. An application's
>> preference file should not be modified (except by the application itself)
>> while the application is running. The script should quit Finder *before*
>> mucking around with its defaults.
>
> FWIW, I've been toggling ShowAllFiles on and off for years using the script I
> posted earlier w/o encountering that so-called bug. Maybe that's becauise I'm
> killing the Finder after each use and the plist file it's running on is stored
> in RAM and upon restart it's grabbing the changed one.
There's a race condition if you update any application's preferences while it's running.
Applications typically read in their preferences at startup, and hold the value in RAM. If you change a setting, the new value is held in RAM and becomes effective immediately, but it's unpredictable when the value gets written back to disk. All that can be said for sure is that, if the application quits normally, the write-back will happen before the application quits.
If you change the file and then tell the application to quit, AND the application is holding onto any unsaved changes, it'll save them at that point, completely overwriting the file and wiping out your changes. If none of the settings have changed since the application launched, the file doesn't need to be overwritten, and your changes may survive. Likewise IF the application flushes unsaved changes to disk periodically, and nothing has changed since the last time it flushed.
The only reliable way to make sure your changes don't get lost AND make sure that any changes the user has made also don't get lost is to let the application quit normally, then change the file, then re-launch the application.
Force quitting the Finder is even worse. Not all of the changes Finder tracks are written to the preference file. For example, window positions, sizes, current view, etc. will eventually get written to .DS_Store files scattered around the filesystem, but Finder rarely bothers to update those files until it quits normally or the disk volume is about to be unmounted.
Try this: Open a Finder window. Move it. Resize it. Change its view. Navigate to a different folder.
Then force-quit Finder.
When it comes back, all those changes are lost. Finder is back to showing the same windows it did the last time it launched.
But even if you don't mind losing your window settings, force-quitting Finder still doesn't address the potential race condition. It could, just by happenstance, decide to write unsaved changes back to its preference file, just in that instant right after you changed the file but before the force quit hits it.
And there's still the question of whatever else Finder was doing at the time. If you force quit ANY application, it doesn't get a chance to clean up after itself, and may leave corrupted data behind. What if it was copying a file, for example?
Force-quitting applications is an extremely rude thing to do, and should not be done if it's possible to terminate the application in any kinder way. You most definitely should not be force-quitting an application just so you can toggle a flag. Reserve the force-quit option for when the application hangs, and refuses to quit even when asked.
(Exception: Dock won't let you ask it to quit. You have no alternative but to force quit it. Update the file first, then cross your fingers and force-quit it. "killall" is Terminalese for "force quit".)
-Ron Hunsinger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden