242037 - mkdir in many perl scripts contains a decimal 775, not the correct octal specification of 0775

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[AllBackJack]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla 1.7b

I've been having problems doing the builds, with bad protection being set on 
certain created directories. I noticed that in a number of perl scripts (*.pl) 
mkdir is invoked with the second argument being a 775, rather than an octal 
value of 0775. When I changed this in some test cases, the build worked. You 
need to correct this in the source.

Reproducible: Always
Steps to Reproduce:
1. Just grep the *.pl files for mkdir, and you'll see what I mean
2.
3.

Actual Results:  
A number of 775's

Expected Results:  
They should be 0775's (or 0777's)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Output of 

find . -name "*.pl" -exec grep -H -n "mkdir.*[^0-9][1-9][0-9]" \{\} \;

from root mozilla dir:

./config/zipcfunc.pl:96:    mkdir("$inTargetPath", 775);
./config/zipcfunc.pl:132:    mkdir("$inDest", 775);
./toolkit/mozapps/installer/makeall.pl:390:     
mkdir("$gDirStageProduct/$mComponent", 775);
./toolkit/mozapps/installer/windows/build_static.pl:110:mkdir("$DEPTH\\stage", 775);
./toolkit/mozapps/installer/windows/makeall.pl:577:     
mkdir("$gDirStageProduct/$mComponent", 775);
./tools/tinderbox/post-mozilla-win32-rel.pl:34:  mkdir  $stagedir, 775;
./xpinstall/packager/windows/makeall.pl:650:     
mkdir("$gDirStageProduct/$mComponent", 775);
./xpinstall/packager/build/scripts/makeall.pl:543:     
mkdir("$inStagePath\\$mComponent", 775);
./xpinstall/packager/os2/makeall.pl:677:  mkdir("$gLocalTmpStage", 775);
./xpinstall/packager/os2/makeall.pl:684:    mkdir("$gLocalTmpStage/$mComponent",
775);
./xpinstall/packager/os2/makeall.pl:732:      mkdir("$inStagePath/$mComponent",
775);
./xpinstall/packager/os2/deliver.pl:116:mkdir("$DEPTH/stage", 775);
./xpinstall/packager/stage_gre.pl:56:  mkdir("$aDirStage", 775) if (!(-e
"$aDirStage"));
./xpinstall/packager/stage_gre.pl:57:  mkdir("$aDirStage/$aProductName", 775) if
(!(-e "$aDirStage/$aProductName"));
./xpinstall/packager/stage_gre.pl:58:  mkdir("$aDirStage/$aProductName/gre",
775) if (!(-e "$aDirStage/$aProductName/gre"));
./xpinstall/packager/win_gre/makeall.pl:579:     
mkdir("$gDirStageProduct/$mComponent", 775);
./xpinstall/packager/win_mfcembed/makeall.pl:612:     
mkdir("$gDirStageProduct/$mComponent", 775);
./xpinstall/packager/stage_mfcembed.pl:58:  mkdir("$aDirStage", 775)           
            if (!(-e "$aDirStage"));
./xpinstall/packager/stage_mfcembed.pl:59:  mkdir("$aDirStage/$aProductName",
775)          if (!(-e "$aDirStage/$aProductName"));
./xpinstall/packager/stage_mfcembed.pl:60: 
mkdir("$aDirStage/$aProductName/mfcembed", 775) if (!(-e
"$aDirStage/$aProductName/mfcembed"));
./xpinstall/wizard/os2/builder/build.pl:108:mkdir("$DEPTH/stage", 775);
./xpinstall/wizard/windows/builder/build_static.pl:92:mkdir("$DEPTH\\stage", 775);

Comment 2

[Andrew Schultz]

Attachment: patch

this patches seamonkey, firefox and tinderbox...

Comment 3

[Benjamin Smedberg]

Comment on attachment 147288 [details] [diff] [review]
patch

r=me, no sr needed

Comment 4

[cls]

*** Bug 241108 has been marked as a duplicate of this bug. ***

Comment 5

[cls]

This patch was checked in on 2004/04/30 .

Comment 6

[Andreas Kunz]

Heh, this patch missed one file because it is a *.pm file...
I already filed bug 245172 for that file (StageUtils.pm) independently, patch is
there.

Comment 7

[Steffen Wilberg]

The checkin from 2004-04-29 21:23 didn't include the changes to mozilla/toolkit:
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=2004-04-29+21%3A23&maxdate=2004-04-29+21%3A23
Reopening.

Comment 8

[Steffen Wilberg]

Do we need this for 1.7? The fix for bug 245172 has approval1.7+.

Comment 9

[Andreas Kunz]

Well, personally I don't really consider it important for 1.7 because it's only
interesting for people producing install packages on NTFS file systems. But
bsmedberg requested and quickly got approval from leaf, so why not request it
here, too?
Only checking in one of these two bugs does not really make sense...

Comment 10

[Steffen Wilberg]

Comment on attachment 147288 [details] [diff] [review]
patch

This is the same as the fix for bug 245172, but for *.pl files. That one
already has approval1.7+.

Comment 11

[Asa Dotzler [:asa]]

Comment on attachment 147288 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to Mozilla 1.7. We're wrapping things
up and so this will need to land today if it's going to make the release.

Comment 12

[Steffen Wilberg]

I don't have a cvs account, can somebody check this in soon, please?

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

I checked the patch here into the 1.7 branch (except tinderbox, which doesn't
seem to have been branched)

Comment 14

[Andreas Kunz]

So there are only aviary issues left to do now:
The three /toolkit files need to be patched on trunk (was not done at trunk
checkin) and the entire patch needs to be landed on the aviary1.0 branch.

Moving to the Firefox product, leaving assignment. I already wrote mconnor a
mail about what has to be done here.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I just merged what landed on the 1.7 branch (all files in attachment 147288 [details] [diff] [review]
except the tinderbox script) onto the aviary branch.  Is that sufficient, or did
something else need to happen?

...other than landing the toolkit files on the trunk, that is.

Comment 16

[Andreas Kunz]

No, that's all. Only the three /toolkit files on trunk left to do now.

Comment 17

[Reed Loden [:reed]]

(In reply to comment #16)
> No, that's all. Only the three /toolkit files on trunk left to do now.

Trunk seems to have these fixes now as a run of the find command from comment #1 returns nothing.

-> FIXED

Please reopen this bug if this is not correct.

Also, I moved this bug to Core and moved fixed-aviary1.0 from the whiteboard to the keywords field where it probably should have been.