site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com Test case: ---------- Destination: relocatable, default destination /Applications/Test\ Case Root folder: a folder containing the CaMarchePasCeTruc application. Permissions required: root authentication OS: 10.4.8 (PPC) _______________________________________________ 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... 1 Carbon application "CaMarchePasCeTruc" with resource fork and data fork in the same file. 1. When I build the package with PackageMaker, the package installs correctly, the CaMarchePasCeTruc application is complete (Data & Resource Fork are merged). 2. When I replace /Developer/Tools/SplitForks with another tool, the installation works OK. 3. When I remove the /bin/pax tool, the package is built correctly. So PackageMaker is not using the pax tool to build pax archives... 4. When I build the same package with a shell script using command line tools including pax, the produced package is exactly the same as seen from the outside: - lsbom states the archives are identical (SplitForks is not used for splitting forks, otherwise due to a bug in SplitForks, the checksum would be different). - when /bin/pax is run from the Terminal to extract the ./._CaMarchePasCeTruc and ./CaMarchePasCeTruc components, they are correctly merged back in both cases. Yet, when you install the package produced by the script, the resources are not merged back. The only difference seems to lie in one using /bin/pax while PackageMaker (in 10.4) is apparently using the private BOM Framework. So it makes one wonder what's the difference between a pax archive produced by /bin/pax and one produced by the BOM Framework (if we put aside the fact that /bin/pax is not ACL compatible when the other solution is). This email sent to site_archiver@lists.apple.com