You can clone with
HTTPS or Subversion.
we are using the version of Sparkle added February 20 2012 in our previous version, Sandvox 2.5.2. (So it looks like it's equivalent Sparkle e27828d.)
We are seeing problems updating when the 2.5.2 application is in a protected folder - for instance, in /Applications, where the current account doesn't have admin permissions, and also that the application doesn't belong to the current user. When the update is installing, there's a request for an admin password coming from finish_installation.
The resulting update is incomplete. Many resources are missing, so the newly installed app crashes immediately as it tries to launch.
I had thought that maybe the fix to #157, 4d00e8c, would solve the problem. However, I built a version of the current master, and shoved it into Sandvox 2.5.2, but the problem happens again.
I'm wondering if you can reproduce this, and help me figure out what might be happening here. You could use the 2.5.2 version of Sandvox as a test-bed; download it from: http://www.karelia.com/files/8/_Sandvox-25058.dmg. Drag this into /Applications from a non-admin account, so we see that you are asked for permissions. Then switch over to another non-administrative account - this seems to be an important step -- and then launch Sandvox and check for updates. You should be asked for admin permissions by finish_installation. When that's done, you should see that the installation is corrupt.
There may be other paths to this -- we have gotten a number of reports from people who can't update -- but this is the one that I was able to reproduce consistently.
Do you think that the fix to #157, 4d00e8c, will solve that problem?
If not, I'm wondering if you can try to reproduce this and see if you have an idea what's happening.
I just updated the title to reflect the fact that the current version of Sparkle should NOT be used in production code. I wish I was a bit more familiar with Xcode 4 to be able to help diagnose this issue, but until we can figure this out, I would really encourage people to avoid trying to use a current build of Sparkle.
I'm sorry for the substantial delay on this, Dan. I'm presently on vacation and without a compiler, but I will try to look at this as soon as I can after I return next week.
Thanks! I figured it was something like that, so I wanted to make sure people were warned of its gravity - I don't see how to make the XXX marks. We've reverted to an earlier Sparkle for now.
Good(?) news: I can reproduce!
And indeed: if I substitute Sparkle.framework built from HEAD, it still exhibits the issue. To which version of Sparkle have you reverted, so I can bisect?
I don't have the exact checkin but it was November 18, so let's say b275cab
I don't understand it yet, but: skipping the "chown" phase of _copyPathWithForcedAuthentication: makes the problem go away. Hm.
Oh, what a fun resolution!
Dan, you'll find you can reproduce this bug with _Sandvox-25096.dmg without Sparkle's involvement:
1. Make two non-admin users, test1 and test2.
2. Log into test1.
3. Mount _Sandvox-25096.dmg and copy Sandvox.app to /Applications. You'll have to authenticate as an administrator.
4. Log into test2.
5. Try to launch /Applications/Sandvox.app.
This is happening because a number of files inside that Sandvox.app (like Growl.framework and some other resources) have permissions of 700. The "installing" user is the only one who can read them, so test2 can't launch the app because he can't read Growl.framework. Updating the app doesn't change its owner (by design), so Sparkle is neither helping nor hurting the situation. Indeed, if you try the same trick with the last version (_Sandvox-25058.dmg), you'll see that it doesn't have any of these 700 files, so it works just fine.
Holy cow! Thanks for the status as you worked through this and your analysis. I wonder if there is something one could put into Sparkle, maybe some console log messages, to point out why something is failing, so that something like this could be avoided in the future?
Hm. I've thought about it, but I'm not sure what the heuristic would be. Warn if the app I'm installing contains any 700-permissioned files which would not be owned by the current user? That seems certain to introduce false positives. Is there a more specific warning I could make?
Here's a thought - Rather than focusing on the permissions, what about the actual result of trying to copy over the new files, and if they fail for some reason, log the fact that there was a failure. That way, somebody could look at the log to get some clue as to why their application won't launch after updating?
Hmm, good point. I dunno then! Well, thanks for your help here!!!!!!!!!!