site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MbUvohEjRhTcXTnIkQooUzx1U88yjHKYOpKLqiuilYZACaVO10E41d9jlC4g71m2og8P3ruSvcxKHbWxPDHA0usrhUcEzq0RgmBxIAAYRAYQSWCs4ENqbYXCrpdMTBjhN+8lg1L7M499MLZEusbGsmpnnjrOqRZtUaVePmNl/i4=; Unfortunately, adding the extra level of folder does not help. It looks like Installer.app just does not know how to turn back on the custom-icon attribute bit.

From the SetFile man page, even though SetFile is in /usr/bin/SetFile, it is present only if developer tools are installed?

I guess none of this is necessary to run iTunes. ----- Original Message ---- Sent: Saturday, December 6, 2008 10:30:30 AM Subject: Re: Keeping a Folder's icon with packagemaker/installer On Dec 5, 2008, at 6:29 AM, Russ wrote:

Battling packagemaker 3.0.1 (172)

The contents I am installing is a folder into /Applications, my app bundle sits in that folder along with the help files. (I am simplifying to reduce techsupport volume). This setup is routine for 3rd party apps, so I am going with the flow.

The problem at hand is that I have set up, using Finder, my icon on my top-level folder to make it easier to find in the Applications list. This results in an Icon? file being created in the folder. After digging around a while I've seen the actual required name is something like \pIcon\r and this file is size 0 with the icon in a resource fork! (I guess a plain hidden .folder.icn file would have been too easy?)

It appears that packagemaker or installer choke on this file, it shows up at the installation, but without the resource fork, extended attributes, and possibly without the special-character name, and of course it does nothing.

Is there a way to get the installed folder's icon set up right, either by installing the Icon? file correctly or some other (simple) method? Adobe CS3 and Snapz Pro X have got it working somehow. I'd just as soon NOT have to create some (Carbon AE) program to go do this programmatically as a post-installation hack. Thanks.

AFAIK: If you set your payload root like this: Payload > My Folder and set the default destination to be '/Applications', you may face this issue. The fact is that SplitForks does not produce the same result twice in this case. If you set your payload root to be like this: Payload > Applications > My Folder and set the default destination to be '/', this issue will not occur.

PS: It is a known bug that Packagemaker likes to turn "Allow Relocation" back on by itself, right? Pretty sure that's what happens. And that if it is on, and the user has dragged the old version of your app to the trash, Installer will (re)install the new version into the trash can, right?

It is a known bug. Not sure if it also applies to the Trash can though. _______________________________________________ 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... This email sent to site_archiver@lists.apple.com