Open neeels opened 7 years ago
I have the same issue, I am trying to format a block device using udisks and mount it afterwards. I can confirm that the proxy object for the ".../block_devices/sdX" object never gets its interfaces refreshed. It gains an interface ".UDisks2.Filesystem" after formatting but that never appears on the proxy.
Ugly workaround is to get a new proxy after formatting.
Over at Osmocom.org we're using ofono to interact with modems. ofono has the peculiarity that a modem represented by a DBus path may have new DBus interfaces appearing or existing ones disappearing e.g. by setting their 'Powered' to 'true' / 'false'. It works like this:
Here is my problem: when I receive that signal and I ask my pydbus object instance that represents the modem for this interface, I get a KeyError.
I dug up pydbus code and noticed that of course, the proxy object is composed from evaluating the Introspection XML. It appears that there is no way to update this list of available interfaces once the object is created: in proxy.py, a new class is defined on-the-fly and instantiated. To benefit from changes in the Introspection information, pydbus needs to define a whole new CompositeObject class and instantiate it. Right?
Simple enough, I can modify my code to fetch a new pydbus object every time this happens. But here's what's annoying: I have already connected signals to this object. When I fetch a new object, I have to cancel all my signal subscriptions and establish new ones. Right?
Added annoyance is that each single new interface is announced in a separate signal. So when N new interfaces come up due to modem power on, I disconnect all and re-connect the signals N times over, in a short time.
My dream would be to have a simple my_proxy.refresh() with signal subscriptions as well as the pydbus proxy object identity remaining valid. What is your stance on this? Thanks!
https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/ofono_client.py https://osmocom.org/issues/2233