Build: 6/29/99 SeaMonkey Linux build 1. User trigger at http://jimbob/trigger2.html 2. Trigger http://jimbob/jars/f_addsubcomp_unixpermissions.jar f = Install.GetFolder("Program", "f_addsubcomp_unixpermissions"); Install.AddSubcomponent(regName, vi, "thefolder/"+jarSrc, f, jarSrc, true); 3. The jarSrc, "smrtupdt.txt", had file permissions changed to -rwxrwxrwx prior to zipping into jar file RESULT: The subdirectory "f_addsubcomp_unixpermission" is created as expected. This subdirectory's file attributes show drwx------. The file "smrtupdt.txt" is installed into "f_addsubcomp_unixpermission" as expected. The file attributes show -rw-r--r--. The Install.log records the triggered jar test correctly. Version registry is incomplete. Related to bug 9053, http://bugzilla.mozilla.org/show_bug.cgi?id=9053 EXPECTED RESULT: The subdirectory should have the permissions, drwxr-xr-x. The file should have the permissions, -rwxr-xr-x. The file was enabled to have executable properties. This property should be retained after the jar file is triggered. The subdirectory should be accessible, and the installed file should have executable permissions enabled.

There are several steps to this bug, and when I start working on it I'll probably create separate bugs for each. 1. we need to make sure common zip tools store this info in the archive. Signtool does, but we don't want to be dependent on that one tool. 2. We have to change libjar to read the central directory rather than the local file headers. This mode information is stored only in the central directory. 3. Only then can we start to worry about preserving that info when we extract the files. 4. We have to decide the rules for replacing a file -- do we use the permissions of the file being extracted, or the permissions of the file we're replacing? The difference could be due to something an admin did explicitly. I'm not referring to the execute bit, but the fact that group/everyone permissions may have been set to read-only, when the file in the archive is r/w

I ran into something interesting that we need to consider as well. After remotely logging into Bindu's machine, I triggered a jar that created a subdirectory under /tmp and added a file into the subdirectory. Because the permissions were for the subdirectory were drwx------, I was unable to acccess this subdirectory. I did login as root, changed the permissions, and verified that the file was added. The issue or question I want to raise is what are the differences to consider when a user versus an owner installs files.

reassign to Dan, per today's bug meeting.

We are now restoring permissions on Unix and Windows and handle the quirks of the Unix "zip" utility (InfoZIP) as well as WinZip and other zip utilities. Fix in hand: contingent upon review this will be checked in once the tree opens post verification builds.

Fix checked in.

Build 1999-11-08-08-M11(LINUX) Most excellent!

Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall Engine

this is broken again. I will attach a xpi file that worked in M13 and is now broken at M14.

Pav fails to mention the implications: we will not be able to upgrade or install executables on any Unix platform. We will not be able to upgrade Linux users to beta2 We will not be able to give SSL to M14 mozilla Linux users

resetting TFV to M14 unless the PDT team decides this is not a beta stopper. Adding mstoltz and warren to the CC list since they also have touched nsJAR code.

Fix in hand. Awaiting review and permission to check in.

Fix checked in.

Build 2000-02-23-08-M14(LINUX) Looks good!