site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com I have a very strange problem with a very simple install. For many revisions now, I have used PackageMaker to create an installer for my ScanTango scanning application. This has worked perfectly up until 10.4.8. The exhibited problem does not occur until the first time the application is run after installlation. At that time, it loads/unloads a series of a half-dozen or so code bundles that attempt to detect and talk to various models of USB-attached scanners that we support. The exhibited problem is that the application sometimes hangs when attempting to do this. I cannot recreate this here in the lab - it has only occured out "in the wild" to about 8-10 of my users. The problem ONLY occurs when the installer installs the application. The problem can be fixed by having the user manually unpack the "Archive.pax.gz" file in the installer to their Desktop and then dragging the application into the /Appplications folder. My PackageMaker project is set up as follows. I am building using PackageMaker 2.1 (10.4.7): Default location : /Applications Package Requirements: none Authentication : Adminstrator Post-Install Action: None Flags: Root Volume Only, Follow Symbolic Links (I've also tried Overwrite Directory Permissions with my app root in the package set to "root:admin" with the same result) No Scripts File Permissions: root:admin rwxrwxr-x No Locator definitions Default file filters for CVS stuff Identifier: com.mindwrap.scantango Version is 2.3 and has been steadily bumped each release NOTES: I had a user do an auto install and a manual-unpack install, then fire up Terminal, go to /Applications and do an "ls -lR ScanTango.app" to see exactly what was installed and the permissions. The ONLY visible difference between the two installs was that on the auto install, the user:group was root:admin and on the manual install it was <username>:admin. All files and permissions identical on both and all file sizes identical on both. Only the manual install would run correctly for those users reporting the problem (some users had no problem with the auto install). The only think that caught my eye was that the application contains two private frameworks. However, the link path is expressed slightly differntly on the two: ScanTango.app/Contents/Frameworks/ScanUSB.framework: total 16 lrwxr-xr-x 1 root admin 28 Dec 14 14:02 Resources -> ./Versions/Current/Resources lrwxr-xr-x 1 root admin 26 Dec 14 14:02 ScanUSB -> ./Versions/Current/ScanUSB drwxrwxr-x 4 root admin 136 Dec 14 14:02 Versions ScanTango.app/Contents/Frameworks/SyscanDll.framework: total 16 lrwxr-xr-x 1 root admin 26 Dec 14 14:02 Resources -> Versions/Current/Resources lrwxr-xr-x 1 root admin 26 Dec 14 14:02 SyscanDll -> Versions/Current/SyscanDll drwxrwxr-x 4 root admin 136 Dec 14 14:02 Versions We don't feel that this could cause any problems. This really feels like a permissions problem, but we can't seem to recreate it in the lab. Anyone else have any similar experiences or have suggestions? Feel free to download the installer from our website and play with it. www.scantango.com -- Craig Landrum Chief Technical Officer mindwrap, inc. Phone: (540) 675-3015 x 229 Fax: (540) 675-3130 email: craigl@mindwrap.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... This email sent to site_archiver@lists.apple.com