Dropbox sync of autokey.json file doesn't work as expected

[GoogleCodeExporter]

Since I've written some time-consuming scripts I'd like to enable syncing of 
those scripts across two machines. I thought this would just be a matter of 
syncing the autokey.json file via Dropbox. 

Here's my problem:

1. On machine1 moved autokey.json to a folder in Dropbox, then created symlink 
back to ~/.config/autokey/
2. Autokey on machine1 continues to access the autokey.json file just fine.
3. On machine2 deleted autokey.json from ~/.config/autokey
4. In its place created a symlink to synced autokey.json file in Dropbox folder.
5. Restarted Autokey on machine2
6. Did not see any of the shortcuts or scripts from machine1. Instead, I still 
saw the scripts that had been present on machine2 prior to syncing. 
7. On checking the autokey.json file in the Dropbox folder, it had been changed 
(!) to contain the old shortcuts and scripts from machine2.

What I would expect is that replacing the autokey.json file would simply change 
the shortcuts and scripts available. Instead the program seems somehow to 
revert the json file.

I'm using version 0.71.2 on Ubuntu 11.04 (fully updated)

Original issue reported on code.google.com by scotti...@gmail.com on 1 Jul 2011 at 9:27

[GoogleCodeExporter]

The problem is that you had AutoKey running on machine2 when you replaced its 
config file with the symlink. When you quit AutoKey, it persists configuration 
as it shuts down, overwriting your symlinked data with what is in memory. So, 
simply make sure AutoKey is not running on machine2 before replacing its config 
file with the symlink.

Original comment by cdekter on 1 Jul 2011 at 10:39

• Changed state: Invalid

[GoogleCodeExporter]

thanks for your reply. The problem is valid, though, for anyone who wants to 
sync their scripts and *has autokey run at system start.* This will mean that 
autokey is always running before Dropbox has a chance to sync the file. Now, 
for the time being I can remove autokey from my systerm startup, but I do think 
that this is a usability snag. After all, autokey is the kind of application 
that people want to have running in the background all the time. It seems to me 
that a fix would involve just checking periodically to see whether the script 
file has changed and updating the version in memory if necessary. 

Original comment by scotti...@gmail.com on 9 Aug 2011 at 6:09

[GoogleCodeExporter]

Fair point... I'm at the point of trying to decide whether to do this kind of 
enhancement or work on a large-scale rewrite... will put this on the TODO list 
for now.

Original comment by cdekter on 9 Aug 2011 at 9:35

• Changed state: Accepted

[GoogleCodeExporter]

Part one of the fix for this is done - don't overwrite the configuration file 
on startup.

Original comment by cdekter on 11 Sep 2011 at 11:31

• Changed state: Started

[GoogleCodeExporter]

Completed for v0.80.0 by implementing real-time configuration reloading using 
inotify

Original comment by cdekter on 16 Sep 2011 at 12:49

• Changed state: Fixed