I have the following scenario: Snap A, B & C provide the slot “assets” using the content interface, allowing Slot X to access the files in the assets folder on the slot side.
Let’s assume that I connect Snap A,B,C (in this order), in my use case resulting in the directories $SNAP_DATA/assets (Snap A), $SNAP_DATA/assets-2 (Snap B), $SNAP_DATA/assets-3 (Snap C) being created.
I have an application running inside Snap X, which uses data provided in $SNAP_DATA/assets, $SNAP_DATA/assets-2, and so on.
Now I disconnect Snap B, which will result that $SNAP_DATA/assets-3 will now be removed and Snap A and Snap C will now use $SNAP_DATA/assets and $SNAP_DATA/assets-2 (most likely in this order, but that to my knowledge is not guaranteed).
Long story short: Because of this effect, I need a cleanup script which updates the configuration of my application running inside Snap X so that the configuration now points to the correct files in the place.
Unfortunately, I can’t execute the cleanup script inside the disconnect-plug-assets hook, because at this time the “outdated” directory still exists. Because of that I tried using the unprepare-plug-assets, but it seems like the hook is never called.
Is there an alternative?
Switching the mechanism (Snap X provides a Slot to which Snap A, B, C connect) is not possible in my use case.
disconnect-plug-* (and disconnect-slot-*) are the hooks to handle disconnecting and such scenarios, they are the right place to do what you are after. I’m not sure if you are aware of this feature, but in interface hooks (including disconnect-plug/slot…) you can use snapctl command to read attributes of both ends of the connection getting disconnected (or prepared and then connected). I think that instead of relying on existence of the directories you should therefore base your logic on attributes of the connection to know what’s getting disconnected; you can even introduce your own attributes in the prepare- / connect- hooks and later look them up in disconnect- hooks if that helps (although I suppose the paths of content interface may be enough).
unprepare- hooks are not executed because they are only run if snap connect fails (they handle the “undo” aspect).
thank you for the clarification regarding the unprepare hook, I assumed that the hook would be executed after a successful disconnect, too.
Unfortunately this means, that I am back to square one regarding my use case.
I know about the snapctl mechanism (I am using it in another scenario), but unfortunately this won’t solve my problem. Let me rephrase / clarify where the problem lies:
I have an application running in Snap X, which uses a configuration file. This configuration file contains references to files (unix sockets, to be precise) which are located in the folder(s) which are provided by Slot A, B, C using the slot/plug mechanism. Slot A, B, C deliver content on the corresponding file and this content is then read by the application in snap X (using the configuration file to determine which socket file belongs to which snap).
The configuration file of the app in Snap X looks like this:
Let’s now assume I disconnect Snap B. Now the directory structure in $SNAP_DATA of Snap X changes and I have to update the references in the configuration file. The configuration file now has to look like this:
To be able to update the references, I have to know the new location of the remaining socket files of Snap A&C, because I can’t determine beforehand how the directory structure looks like after the removal of Snap B (please correct me if I’m wrong here). I also can’t determine the new locations when I run the disconnect hook, because at this time the soon-to-be-removed directory of Snap B still exists. Therefore I need a hook or something similar which is triggered as soon as the disconnect has happened.
I hope I was able to clarify the exact problem a little bit more.
