Ticket #3707 (new defect)
Bundle registry file monitoring clashes with its own operations
|Reported by:||dsd||Owned by:||erikos|
|Priority:||Unspecified by Maintainer||Milestone:||Unspecified by Release Team|
There are several races within bundleregistry.py because the gio file monitor does not collaborate with the install/remove/upgrade operations in the file.
For example, on an upgrade, the code first uninstalls the old version (by deleting the whole activity dir tree) and then calling self.remove_bundle() to remove it from self._bundles. However, the file monitor will *also* notice the file deletion (uninstallation) and call self.remove_bundle. One of the two will fail.
Then, continuing with the upgrade, install() is called to install the new bundle, first unpacking the bundle and then calling self.add_bundle(). However, during the unpack, the file monitor will also note the presence of the new activity and call self.add_bundle(). One of the two calls will fail as the bundle is already present.
I suspect this is the cause of http://dev.laptop.org/ticket/11373
This behaviour can be seen by sprinkling a few debug log messages in bundleregistry.py then upgrading an activity via the journal or the activity updater.
Reproduced with sugar-0.96.3.