site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Lying to the installer by hacking the BOM is a very bad idea. -pmb Does your updater have the same name and bundle ID as the full installer? I'm not sure whether this behavior is actually documented anywhere, but we've found that when you install a new package that has the same name as an old package already in /Library/Receipts, if the .bom file in the old package lists any installed files that do not exist in the new package's .bom file, the Installer will often delete such files (presumably under the assumption that the files are obsolete). From: Robert Carroll <robc@total.net> Date: Sun, 9 Sep 2007 23:50:29 -0400 To: <installer-dev@lists.apple.com> Subject: packagemaker update problems Thanks for your reply Stephane. The full installer of my application bundle includes a folder inside "Resources" with a set of sound files. Since these files do not change with the updates, I do not include them in the updater package. In testing on my machines, if I don't at least leave the empty "Sounds" folder in the Resources folder, the update appears to delete this folder and its contents. Leaving the directory structure in place, correctly leaves the required sound files post update on my machine, but seems to still remove these files on some user's machines. I am trying to verify this. On Sep 8, 2007, at 3:05 PM, installer-dev-request@lists.apple.com wrote: the client's currently installed version. files or the encrypted registration info) and doesn't not replace or change anything elsewhere on the computer. accomplish this kind of update? Regarding the permissions issues: - Which OS version is the update run on when it does not work? Regarding the "does not runt at all" issue: moved by the customer? you split fork when you're creating the packages? I'm not using resource forks, however the sound files still have resource fork data. I would like to confirm that this data is not essential. At the moment the resource fork data is being preserved in the installer & updater pkgs. best wishes, Robert Carroll RSM Records Toronto http://www.rsmrecords.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/bierman%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... The behavior you're confused about is actually the basis of the existence of the installer as opposed to just using tar or zip. When the installer detects that a different (not just older) version of the "same package" is already installed, it will remove any files that were installed by the previous version that are no longer part of the new version. At 10:40 AM -0500 9/10/07, Steve Stockman wrote: The solution was simple: Build both the full installer and the updater, and then replace the updater's .bom with a copy of the full installer's. And the Installer never seems to complain about files named in the .bom that don't exist in the archive. ---------------------------------- Steve Stockman Software Architect Consumer Products - Macintosh Symantec Corporation www.symantec.com ---------------------------------- One cause of the problem with the updater has been somewhat identified. The updater is set up to replace the app file in the MacOS folder of It shouldn't touch any other files in the same package (ie. resource Is this a known issue? Is there a safer and more reliable way to - Which authorization are you requiring? I'm requiring administrator privileges to run either the installer or the updater. The files in the package mostly show me as the owner, read-only privileges or read-execute for others. Is it normal to leave myself as the owner, or more common to set this as root or something else? The resources folder must have read-write privileges for everyone, since the app will write encrypted registration data to this folder on its first run. It's possible this would be better if it was in the application support folder, but I prefer the concealed location in the app package. - Do you use a default location that is not '/'? No. - Do you take into account the fact that the application may have been - Do you use a Locator to look for the location of the application? This is a valid concern. I don't currently check the installed file location, which would obviously foil the update.

- Do you use Resource Fork for resources in your application? If so, do This email sent to bierman@apple.com This email sent to site_archiver@lists.apple.com