10147 - [PP]addFile: Long file names (32 chars) not correctly handled

Status: VERIFIED FIXED

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

Description

[Jimmy Lee]

Build: 7/16/99 SeaMonkey build

1. From http://jimbob/trigger2.html, open
   http://jimbob/jars/f_addsubcomp_longfilename.jar

2. Using the form:
      Install.AddSubcomponent(regName, vi, jarSrc,f,
                                      "1234567890123456789012345678.txt", true);

RESULT:
Install.log indicates successful installation.  Version Registry appears with
correct version info and path.  The file gets installed as "-2".  A file, "-1",
also is installed.

EXPECTED RESULT:
File gets installed as "1234567890123456789012345678.txt" or an error message is
received and reflected in Install.log.  "-1" is not installed.  I'm not sure
what this file is about.

Windows accepts this long file name.  Bug 10131 blocks me from verifying this
for Unix.

Comment 1

[Doug Turner (:dougt)]

The error code is wrong, but it definitly is a bug to install a file with a name
longer than 31 chars on mac.

Comment 2

[Cathleen]

setting target milestone to M14, per today's bug meeting.

Comment 3

[leger]

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

Comment 4

[Daniel Veditz [:dveditz]]

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

Comment 5

[Cathleen]

we need to return a proper error code for long filename
mac - 32 chars
win - 150 chars?
unix - ?

Comment 6

[dbragg]

Fixed.  Now windows is 128, Mac is 31 and Unix is 1024.  

Comment 7

[Jimmy Lee]

Build 2000-02-09-09-M14(WIN), 2000-02-09-08-M14(MAC), 2000-02-09-14-M14(LINUX)

Looks good.  Mac aborts as expected because the target file name is greater than 
31 characters.

Comment 8

[Daniel Veditz [:dveditz]]

The fix for this bug is incorrect, the length check is rather simple-mindedly 
applied to the subdir parameter meaning the total length of all  potential 
subdirectories would have to be less than 31. This check should instead be 
applied to each node of the path.

The fix also does nothing for the case where the passed-in nsInstallFolder path 
contains nodes > 31 on a Mac. Maybe nsILocalFileMac already prevents this.

Comment 9

[Daniel Veditz [:dveditz]]

Any check like this should go into nsInstallFile instead, I think

Comment 10

[Jimmy Lee]

Changing "AddSubcomponent" to "addFile" in Summary to reflect new API naming.

Comment 11

[David Epstein]

On Mac (2000-10-30-08-MN6 build), go to http://jimbob/trigger3.html. Trigger 
f_addfile_longfilename.xpi. This one calls a file with 32 chars (31 is the Mac 
limit). What's happening with this is that a "-1" file gets created on the HD. 
In the logfile, it says "replacing", which is incorrect. It also indicates 
successful install, restart required; but the complete install pathway is 
missing. 

Here's the logfile:

-------------------------------------------------------------------------------
http://jimbob/jars/f_addfile_longfilename.xpi  --  10/30/2000 16:51:13
-------------------------------------------------------------------------------

     Functional: f_addfile_longfilename
     ----------------------------------

     [1/1]	Replacing: Macintosh HD:Netscape Folder:

     Install completed successfully, restart required
     Finished Installation  10/30/2000 16:51:13

Comment 12

[dbragg]

When I originally wrote the fix for this I didn't know we allowed a script
writer to put directories into the target.  Posting a fix that checks all the
directory nodes as well as the filename itself.

Comment 13

[dbragg]

Attachment: Check for long directory and file names as well as fix for 61346

Comment 14

[Daniel Veditz [:dveditz]]

Resetting target field for missed milestones

Comment 15

[Daniel Veditz [:dveditz]]

Did this ever get checked-in?

Comment 16

[dbragg]

No it didn't.  You did a review and suggested I make a bunch of other changes
while I was in there that didn't pertain to the bug.  You also said this bug was
a very low priority so I haven't looked at it since.  If you feel I should fix
this bug I'd like to suggest that I just fix the bug and not do any of the
suggested anciallary work.  Whaddaya think?

Comment 17

[Daniel Veditz [:dveditz]]

Moz 0.9 tasks

Comment 18

[dbragg]

Attachment: New, more efficient patch. (using -u10 for clarity)

Comment 19

[Daniel Veditz [:dveditz]]

Looks good, r=dveditz for 3/5 patch

The wide-to-narrow casting here is problematic. Not a problem in Mozilla 
installs since we've avoided int'l chars in filenames and subpaths, but will 
bite us later.

Please file a bug on this issue for XPInstall in general and nominate it. I 
don't think you should fix it just here as part of this bug because then we'll 
be inconsistent. As it is we can sidestep the problem if we know the rules, 
fixing it in only one place makes that harder.

Comment 20

[Scott MacGregor]

sr=mscott

Comment 21

[dbragg]

Fix checked in.

Comment 22

[Jimmy Lee]

Build: 2001-03-09-11-trunk(MAC)

We correctly cancel out of the script.  No file is installed.  Marking Verified!