92107 - Error 215: XPInstall installs jar files as read-only, can't overwrite with later versions

Status: VERIFIED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[bartmess]

I am installing a package using the bare-bones install script below.  It
installs the jar file as read-only, and if I try to reinstall a later version,
the install fails because it can't overwrite the first version (error 215 shows
up in the install.log file).  

     Changing the version numbers doesn't make a difference.  No instructions
for installing the jar file as writeable appear in the documentation.  For
sample behavior, see the download of Annozilla, which also installs as a
read-only jar file on my machine (running Red Hat 6.2).  


// initInstall(name + version, name, version); 
var err = initInstall("Roadmap 2", "Roadmap", ""); 
logComment("initInstall: " + err);

addFile("roadmap",      // displayName from contents.rdf 
"roadmap.jar", 	        // jar source 
getFolder("Chrome"),      // target folder 
"");                       // target subdir 

// registerChrome(TYPE, location, source)
registerChrome(PACKAGE | DELAYED_CHROME, getFolder("Chrome","roadmap.jar"),
"content/");
if (err==SUCCESS)
  performInstall(); 
else
  cancelInstall(err);

Comment 1

[Daniel Veditz [:dveditz]]

The install will preserve the permissions stored with the files in the .xpi 
archive. If you've got an executable then you'd better have the executable bits 
set, and if you don't want it read-only then you'd better set the writable bit 
before running zip to package the archive.

There is a different bug about what the install should do with a read-only file 
that it has permission to chmod. Some argue that the user may have marked the 
file read-only to protect it and we should honor that, and others argue that 
the user asked for an install and we shouldn't fail if we had the chance to do 
the right thing. But that's a different argument than this bug which is simply 
how to install the files writable in the first place.

Comment 2

[bartmess]

When I jar my file (roadmap.jar) into a .xpi file, and then unjar the .xpi file,
the roadmap.jar file has permissions of -rw-r--r--.  When I install the same
.xpi file through Mozilla, the installed roadmap.jar file has permissions of
-r--------.  XPInstall does not appear to be preserving the permissions that the
files in the .xpi file have.   

Comment 3

[Jimmy Lee]

From http://www.mozilla.org/quality/smartupdate/xpinstall-trigger.html, choose
f_adddirfile_permissions from the Functional drop-down and click Trigger case
button to install.  I did this, and I got the expected results of files with
specified permissions.

The install script:
////////////////////////////////////////////////////////////////////////////////////////
// f_adddirfile_permissions.js
// 
// Functional test
// 	? This test installs 4 text files (smrtupdt1.txt, smrtupdt2.txt, smrtupdt3.txt,
//        and smrtupdt4.txt) that have different file permissions
//           smrtupdt1.txt = r--r--r--
//           smrtupdt2.txt = rw-rw-rw-
//
     smrtupdt3.txt = rwxrwxrwx
//
     smrtupdt4.txt = r-xr-xr-x
// 	? addDirectory is used to add various directories which contain files and/or
//        subdirectories with specific permissions.  The directories, /100r,
/100rw, 
//        /100rx, and /100rwx each contain 100 files.
//           /100r
//
     /100rw
//           /100rx
//           /100rwx
//
     /perms
//              smrtupdt1.txt = r--r--r--
//              smrtupdt2.txt = rw-rw-rw-
//
        smrtupdt3.txt = rwxrwxrwx
//
        smrtupdt4.txt = r-xr-xr-x
//              /readexecute
//                 smrtupdt1.txt = r--r--r--
//                 smrtupdt2.txt = rw-rw-rw-
//
           smrtupdt3.txt = rwxrwxrwx
//
           smrtupdt4.txt = r-xr-xr-x
//
	   /readwrite
//                    smrtupdt1.txt = r--r--r--
//                    smrtupdt2.txt = rw-rw-rw-
//
              smrtupdt3.txt = rwxrwxrwx
//
              smrtupdt4.txt = r-xr-xr-x
//
////////////////////////////////////////////////////////////////////////////////////////

var regName1 = "100r";
var regName2 = "100rw";
var regName3 = "100rx";
var regName4 = "100rwx";
var regName5 = "perms";
vi = "1.1.1.1";
var jarSrc1 = "smrtupdt1.txt";
var jarSrc2 = "smrtupdt2.txt";
var jarSrc3 = "smrtupdt3.txt";
var jarSrc4 = "smrtupdt4.txt";

initInstall("Functional: f_adddirfile_permissions", "permissions", vi, 1);
f = getFolder("Program");

s1 = addFile("smrt1", vi, jarSrc1, f, jarSrc1, true);
logComment("addFile smrtupdt1.txt returns = " + s1);

s2 = addFile("smrt2", "1.1.1.2", jarSrc2, f, jarSrc2, true);
logComment("addFile smrtupdt2.txt returns = " + s2);

s3 = addFile("smrt3", "1.1.1.3", jarSrc3, f, jarSrc3, true);
logComment("addFile smrtupdt3.txt returns = " + s3);

s4 = addFile("smrt4", "1.1.1.4", jarSrc4, f, jarSrc4, true);
logComment("addFile smrtupdt4.txt returns = " + s4);

err1 = addDirectory(regName1, vi, "100r", f, "100r", true);
logComment("addDirectory 100r returns = " + err1);

err2 = addDirectory(regName2, vi, "100rw", f, "100rw", true);
logComment("addDirectory 100rw returns = " + err2);

err3 = addDirectory(regName3, vi, "100rx", f, "100rx", true);
logComment("addDirectory 100rx returns = " + err3);

err4 = addDirectory(regName4, vi, "100rwx", f, "100rwx", true);
logComment("addDirectory 100rwx returns = " + err4);

err5 = addDirectory(regName5, vi, "perms", f, "perms", true);
logComment("addDirectory perms returns = " + err5);

if (0 == getLastError())
	performInstall();
else
	cancelInstall();

Comment 4

[bartmess]

I thought perhaps my problem might be a difference in the install scripts, so I
copied the one above and altered it to install my package, as follows.  It still
installs as -r--------, although the one above appears to install correctly.  

I don't know what the difference could be; it's possible I have something wrong
in my install script, but it's difficult to tell because the documentation for
install scripts is different at http://www.mozilla.org/projects/xpinstall/, and
at xulplanet.com, and the example above from which I copied is different from
either one (addFile here has more parameters than it does in the documentation,
as does initInstall).  


vi = "1.1.1.1";
var jarSrc1 = "roadmap.jar";

initInstall("Roadmap", "permissions", vi, 1);
f = getFolder("Chrome");

s1 = addFile("roadmap.jar", vi, jarSrc1, f, jarSrc1, true);
logComment("addFile roadmap.jar returns = " + s1);

registerChrome(Install.CONTENT , getFolder("Chrome", "content"));


if (0 == getLastError())
	performInstall();
else
	cancelInstall();

Comment 5

[Daniel Veditz [:dveditz]]

Regardless of number of arguments, all variants of addFile (and 
addDirectory) all come down to the same thing when dealing with archive file 
permissions.

Jimmy: please try an archive permission test where the user permissions differ 
from the group and world permissions as reported in this bug (e.g. rw-r--r-- 
rather than rw-rw-rw- as in your test). The zip archiver we're using may be 
coding permissions wrong.

Bartmess: what archiver are you using? perhaps yours stores permissions in a 
different option field than we found documented. Also, please try permissions 
like rw-rw-rw- to get a second confirmation on my suspicion above.

Comment 6

[Jimmy Lee]

I'm going to attach the xpi test that I have.  This test works for me as
documented in the install script.  I am seeing the different permissions. 
Hopefully, we can figure out what is the difference.

//////////////////////////////////////////////////////////////////////////////////
// f_addfile_diffpermissions
// 
// Functional test
// 	? This test installs 4 text files (xpinstall1.txt,xpinstall2.txt,
//        xpinstall3.txt, and xpinstall4.txt) that have different file
//        permissions
//
//           xpinstall1.txt = rwxrw-r-x
//           xpinstall2.txt = rw-rwxr--
//
     xpinstall3.txt = r-xrw-rwx
//
     xpinstall4.txt = r--rwx-wx
//
// ~ XPInstall QA
//   July 26, 2001
//
//////////////////////////////////////////////////////////////////////////////////

vi = "1.1.1.1";
var jarSrc1 = "xpinstall1.txt";
var jarSrc2 = "xpinstall2.txt";
var jarSrc3 = "xpinstall3.txt";
var jarSrc4 = "xpinstall4.txt";

initInstall("Functional: f_addfile_diffpermissions", "diffpermissions", vi, 1);
f = getFolder("Program");

s1 = addFile("smrt1", vi, jarSrc1, f, jarSrc1, true);
logComment("addFile xpinstall1.txt returns = " + s1);

s2 = addFile("smrt2", "1.1.1.2", jarSrc2, f, jarSrc2, true);
logComment("addFile xpinstall2.txt returns = " + s2);

s3 = addFile("smrt3", "1.1.1.3", jarSrc3, f, jarSrc3, true);
logComment("addFile xpinstall3.txt returns = " + s3);

s4 = addFile("smrt4", "1.1.1.4", jarSrc4, f, jarSrc4, true);
logComment("addFile xpinstall4.txt returns = " + s4);

if (0 == getLastError())
	performInstall();
else
	cancelInstall();

Comment 7

[Jimmy Lee]

Attachment: This test case adds files with different file permissions for owner, group, and others

Comment 8

[Jimmy Lee]

Attachment: Let's try attaching again!

Comment 9

[Jimmy Lee]

I'm not sure which is the correct way to attach a xpi.  It doesn't seem to work
for me.  I'll have to find out.  Stay tuned!

Comment 10

[Daniel Veditz [:dveditz]]

I can save both attachments and open them with WinZip -- what are you seeing as 
the problem?

Comment 11

[bartmess]

I tried installing a jar file with both files (roadmap.xpi and roadmap.jar) set
to rw-rw-rw-.  It still installs as r--------.  

I'm using the jar that ships with version 1.2.2 of the Blackdown
jdk on Linux.

Comment 12

[bartmess]

This may be relevant:

I went to the barley package sample page
(http://www.mozilla.org/docs/xul/xulnotes/xulnote_packages.html) and tried
downloading barley.xpi by clicking on the link, unjarring the file, and looking
at the permissions of the jar file.  I also installed the package and examined
the permissions.  They were different depending on whether I downloaded and
unjarred it, or installed it.

Downloaded and unjarred:  -rw-r--r--
Installed:                -rw-rw-rw-

Comment 13

[bartmess]

I tried archiving the files using zip instead of using jar, and it now installs
with the correct permissions, so it does appear to have been an issue with the
archiver I was using (again, the jar that ships with version 1.2.2 of the
Blackdown jdk on Linux).  

Comment 14

[Jimmy Lee]

Nominating.

Comment 15

[Syd Logan]

fixed based on comments added 8/3

Comment 16

[Jimmy Lee]

Marking Verified based on previous comments.