July 2007 - Installer-dev - lists.apple.com

Re: detect previous installation
by Stéphane Sudre 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Some common solutions: - or you could save it into the Internet Config data base - if your program runs as root, you have plenty of locations to hide it. On vendredi, juillet 20, 2007, at 07:47 PM, Chad Wagner wrote: On Jul 20, 2007, at 1:39 PM, Michael Watson wrote: There is no facility of this sort, and for good reason. :-) _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… - save a file with the timestamp in a not obvious location or using invisible, '.' prefix tricks. - depending on whether you want different user accounts on the same machine to be eligible for a demo period or not, you may want to save this timestamp in a location accessible by all users. - let user access to demo mode by providing them a serial number that expires. I'm just trying to prevent (within reason) the user from defeating a timed demo period. I probably missed it, but what is the overall goal you're trying to accomplish? This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Chad Wagner 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jul 20, 2007, at 1:39 PM, Michael Watson wrote: There is no facility of this sort, and for good reason. :-) -- m-s On 20 Jul, 2007, at 12:52, Chad Wagner wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I'm just trying to prevent (within reason) the user from defeating a timed demo period. I probably missed it, but what is the overall goal you're trying to accomplish? maybe there is something that the OS maintains that the user can't undo _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/chad% 40chadawagner.com This email sent to chad(a)chadawagner.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Michael Watson 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com There is no facility of this sort, and for good reason. :-) -- m-s On 20 Jul, 2007, at 12:52, Chad Wagner wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I probably missed it, but what is the overall goal you're trying to accomplish? maybe there is something that the OS maintains that the user can't undo This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Chad Wagner 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com thanks for the quick response! I guess I'm hoping for too much, but hoping nonetheless... thanks, cw On Jul 20, 2007, at 12:27 PM, Fritz Anderson wrote: On 20 Jul 2007, at 11:16 AM, Chad Wagner wrote: — F _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… yes, I agree about the "evil" bit. I'm trying to avoid things like that, and a user savvy enough to remove all other files will probably find that one too anyway. it's just hard to be such a "good" developer when there are a number of "evil" users out there (though hopefully a minority)... I'm trying to think, what would I as a user think to do to "completely" uninstall a program, and I would certainly delete any preferences, receipts, etc. I was hoping maybe there is something that the OS maintains that the user can't undo (short of a clean re- install of the OS) such that I could determine that "com.mycompany.mypackage" had already been encountered. kind of like a file ID reference that can't be changed and will never be reused, but as far as I know there's no way of getting a file ID reference for a file that used to exist but has since been deleted. is there way that I can check during my installation whether my software has been installed before, even if it has since been completely uninstalled? any advice appreciated, thanks! If you mean _completely_ uninstalled — meaning that all trace of the software having been there is undetectable, then obviously you can't detect it. Most users are not so thorough. You might look for the preference file, or for the receipt (/Library/Receipts) from a previous installation. Your software might place an invisible "breadcrumb" file of zero length somewhere in the system for later installations to discover, but putting unauthorized files on other people's computers is evil. This email sent to site_archiver(a)lists.apple.com

1 0

Re: detect previous installation
by Fritz Anderson 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On 20 Jul 2007, at 11:16 AM, Chad Wagner wrote: — F _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… is there way that I can check during my installation whether my software has been installed before, even if it has since been completely uninstalled? any advice appreciated, thanks! If you mean _completely_ uninstalled — meaning that all trace of the software having been there is undetectable, then obviously you can't detect it. Most users are not so thorough. You might look for the preference file, or for the receipt (/Library/Receipts) from a previous installation. Your software might place an invisible "breadcrumb" file of zero length somewhere in the system for later installations to discover, but putting unauthorized files on other people's computers is evil. This email sent to site_archiver(a)lists.apple.com

1 0

detect previous installation
by Chad Wagner 20 Jul '07

20 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com is there way that I can check during my installation whether my software has been installed before, even if it has since been completely uninstalled? any advice appreciated, thanks! _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Quitting applications on InstallationCheck
by Bill Coderre 19 Jul '07

19 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com On Jul 19, 2007, at 2:42 PM, Fritz Anderson wrote: I want to quit an application before I overwrite it or its preferences. At present, I have preinstall/preupgrade simply use osascript to quit the application. This is not a good experience, as having the application save or not save its documents will be wrong some of the time; and having it ask leaves the possibility the user will cancel the quit. The better thing to do would be to stall the installation until the user quits the application. I've seen Apple Software Update installers refuse to proceed unless, for instance, iTunes has been quit; it posts an alert with the objection, and reasserts it so long as iTunes is running. I gather from Googling lists.apple.com that this is a problem with a known solution, which has been discussed extensively and optimized. This sounds better than my Braille-ing it out for myself, but I can't get that solution out of Google. Can someone please refer me to it? Apple's policy (which is not followed 100%) is to put up an error immediately if the target app is running. To do this, check for the app running in your InstallationCheck script (or similar part of the distribution script), and just return an error. This means that the user has to switch to the other app, save and close, quit the installer, and then re-run the installer. That's a bit lame, but. There's two other possibilities, which are used occasionally: 1) If you KNOW for a FACT that the user will not lose data, you COULD have the installer quit the app, forcibly. Apple used to do this with iTunes, but we don't do that any more because iTunes might be downloading a movie you paid for, or syncing with a phone, or something. 2) You could allow the install to start, and then, during preflight, call an app to put up an alert asking the user to quit the app, staying stuck in a loop until they actually quit. Apple does this with software updates, but that's because there's no other real choice in the matter. It's bad because we're stuck in a loop, and if the user has left software update running overnight, they'll be cranky the next morning. It's required because a preflight cannot abort installation. For these reasons, Apple doesn't use this modality during a regular software installation, for the most part. I'm going to suggest you stick with the suggested policy, since it's the lesser of evils. If you wanted to be extremely powerful, you could write a helper app that is called during InstallationCheck, which would test if the target app is running, show an alert if so, send a quit apple event to the app and bring it to the front, and then, when returning to the helper app, decide if the target app is quit, and if so, return noError. It would also have a "Cancel" button that returns an error to the InstallationCheck. You can write some slightly clever code to say "If Installer.app is the frontmost app, make ME the frontmost app" which will make it look like the program is part of the Installer.app. The only drawback to this is that the user will get the security alert ("The package contains a program that determines if the software can be installed!"). And that it's a good sized piece of code. And yes, it would be great if the Installer.app did this someday. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Quitting applications on InstallationCheck
by Fritz Anderson 19 Jul '07

19 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com — F _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… I want to quit an application before I overwrite it or its preferences. At present, I have preinstall/preupgrade simply use osascript to quit the application. This is not a good experience, as having the application save or not save its documents will be wrong some of the time; and having it ask leaves the possibility the user will cancel the quit. The better thing to do would be to stall the installation until the user quits the application. I've seen Apple Software Update installers refuse to proceed unless, for instance, iTunes has been quit; it posts an alert with the objection, and reasserts it so long as iTunes is running. I gather from Googling lists.apple.com that this is a problem with a known solution, which has been discussed extensively and optimized. This sounds better than my Braille-ing it out for myself, but I can't get that solution out of Google. Can someone please refer me to it? This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid tool - repair permissions
by Chad Wagner 16 Jul '07

16 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: setuid tool - repair permissions
by Julian Devlin 16 Jul '07

16 Jul '07

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0