Programmatically changing Dock preferences

Question

Hi,
Using OS X 10.6.8, I am trying to programmatically change Dock settings to enforce some security guidelines at our company.
Everything is done through a perl script, and works absolutely flawlessly when I run it locally on the computer I want to change, logged on as myself.
Here is a basic snippet of what I've got:
#!/usr/bin/perl
$user = "bob";
$file = "/Users/$user/Library/Preferences/com.apple.dock";
# Force Top-Right hot corner to "Start Screen Saver"
`defaults write $file wvous-tr-corner -integer 5`;
`defaults write $file wvous-tr-modifier -integer 0`;
`killall Dock`;
However, when the change is executed from our policy server, it is doing something odd...The change is made to the dock plist file, however the Dock is reset to the system default settings. It looks like this only happens if the script actually makes a change. (i.e., if wvous-tr-corner was already set to 5, that would blow away the dock preferences) If we do not kill the Dock, the changes do not take effect, so we need a way to kill the Dock without it reverting back to the system default settings.
We can also duplicate this by issuing the "defaults write"  and "killall" commands via Terminal. Note the "sudo"... When this script gets evoked from the policy server, it is called with a sudo, so we included it in our testing on the Terminal.
For example:
1.) Remove an icon or two from the Dock
2.) "sudo defaults write /Users/bob/Library/Preferences/com.apple.dock wvous-tr-corner -integer 5"
3.) "killall Dock"
4.) Once the Dock restarts, the icons removed in Step 1 reappear
Anybody know what is going on here? Is there any way to restart the Dock so that ~our~ changes take effect immediately, but the Dock doesn't revert back to the System default?
Thanks!

Answer 1

Problem Solved.
When we were running the script, it was being executed as root, which means the "defaults write" commands were also being executed as root. This ended up changing ownership of the file from the user who was supposed to be the owner to root, such that when the "killall Dock" statement was issued, it could not read the plist file, and freaked out and replaced it with the system default.
After we are done with all "defaults write" statements, and immediately prior to issuing the "killall Dock" statement, we added the following:
`chmod 0600 $file.plist`;
`chown bob:bobsgroup $file.plist`;