this is not a bug report per-se but rather a request for an enhancement that would be in the best interest of users of apps using Squirrel.
Squirrel allows apps to implement auto-update functionality, which is great. however, some users prefer to have software that can keep all their apps up-to-date at once as this has various benefits. we are offering one of those products [1], but there are other solutions on the market, both open-source as well as commercial.
all in all, our product works great [2] and can update more than 5000 apps with the click of a button. however, there is a rare problem when our product tries to update an app, while the app also tries to update itself at the very same point-in-time using Squirrel. this can lead to failures on either end, and i guess in the absolute worst case it could even leave the user with a destroyed app. this is uncool.
this report is about preventing this problem in the interest of all users of apps with Squirrel that also use an app-updater (ours or any other).
note that we try to be /very/ careful when updating an app and we have a long array of protection-measures [e.g. we have a good look if the 'ShipIt' process inside the app-bundle is running] and sanity-checking but our logfiles still indicate that some updates fail because a concurrent update has been performed.
this issue happens especially because Squirrel will update apps transparently without asking the user - after the app has quit. when a user asks our app to update an app our app will ask the app-to-be-updated to quit, in order update it - but this is exactly the time when your transparent update-at-quit code kicks in: perfect collision course. we should avoid problems here.
long story short we'd like to prose a solution to avoid any app-updater trying to update an app at the very same time as it also tries to update itself. i imagine a solution has two parts:
1.) a way for Squirrel to tell the outside world that it is going to update the host app. if this 'flag' is set then no outside app-updater should try to update this app
2.) a way for app-updaters to tell Squirrel not to update its host app because an update is already being performed by the app-updater
so, whoever comes first "wins" and should continue doing the update without having to fear that the other party will do it at the same time. basically we need a mutex/lock for app-updates.
implementing a completely safe/atomic IPC lock is probably hard and/or overkill but even a simple implementation could greatly help to prevent the discussed problem.
i haven't put too much thought into it since i want to hear your preferences here first but i suppose we could use either a lockfile or NSDistributedNotification's for this. a lockfile is probably better, unless the 'sandbox' comes into play but i am not sure how many of apps using Squirrel are sandboxed.
we realise that while you may want to see this issue fixed in the interest of users of apps using Squirrel you may not want to put a lot of effort into it yourself. so, we are fully prepared to implement a solution and contribute it to your project. the only thing we would need is
1.) a confirmation beforehand that the contribution will be accepted into Squirrel
2.) some guideline how a solution needs to look to be acceptable
3.) maybe some small pointers where/how best to implement it :)
[1] https://www.corecode.io/macupdater/index.html
[2] which is a totally unbiased statement
this is not a bug report per-se but rather a request for an enhancement that would be in the best interest of users of apps using Squirrel.
Squirrel allows apps to implement auto-update functionality, which is great. however, some users prefer to have software that can keep all their apps up-to-date at once as this has various benefits. we are offering one of those products [1], but there are other solutions on the market, both open-source as well as commercial.
all in all, our product works great [2] and can update more than 5000 apps with the click of a button. however, there is a rare problem when our product tries to update an app, while the app also tries to update itself at the very same point-in-time using Squirrel. this can lead to failures on either end, and i guess in the absolute worst case it could even leave the user with a destroyed app. this is uncool.
this report is about preventing this problem in the interest of all users of apps with Squirrel that also use an app-updater (ours or any other).
note that we try to be /very/ careful when updating an app and we have a long array of protection-measures [e.g. we have a good look if the 'ShipIt' process inside the app-bundle is running] and sanity-checking but our logfiles still indicate that some updates fail because a concurrent update has been performed.
this issue happens especially because Squirrel will update apps transparently without asking the user - after the app has quit. when a user asks our app to update an app our app will ask the app-to-be-updated to quit, in order update it - but this is exactly the time when your transparent update-at-quit code kicks in: perfect collision course. we should avoid problems here.
long story short we'd like to prose a solution to avoid any app-updater trying to update an app at the very same time as it also tries to update itself. i imagine a solution has two parts:
1.) a way for Squirrel to tell the outside world that it is going to update the host app. if this 'flag' is set then no outside app-updater should try to update this app
2.) a way for app-updaters to tell Squirrel not to update its host app because an update is already being performed by the app-updater
so, whoever comes first "wins" and should continue doing the update without having to fear that the other party will do it at the same time. basically we need a mutex/lock for app-updates.
implementing a completely safe/atomic IPC lock is probably hard and/or overkill but even a simple implementation could greatly help to prevent the discussed problem.
i haven't put too much thought into it since i want to hear your preferences here first but i suppose we could use either a lockfile or NSDistributedNotification's for this. a lockfile is probably better, unless the 'sandbox' comes into play but i am not sure how many of apps using Squirrel are sandboxed.
we realise that while you may want to see this issue fixed in the interest of users of apps using Squirrel you may not want to put a lot of effort into it yourself. so, we are fully prepared to implement a solution and contribute it to your project. the only thing we would need is
1.) a confirmation beforehand that the contribution will be accepted into Squirrel
2.) some guideline how a solution needs to look to be acceptable
3.) maybe some small pointers where/how best to implement it :)
[1] https://www.corecode.io/macupdater/index.html
[2] which is a totally unbiased statement