Closed Bug 10147 Opened 23 years ago Closed 21 years ago

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

Categories

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

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.8.1

People

(Reporter: jimmykenlee, Assigned: dbragg)

References

Details

(Whiteboard: [xpibug])

Attachments

(2 files)

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.
Target Milestone: M12
The error code is wrong, but it definitly is a bug to install a file with a name
longer than 31 chars on mac.
Status: NEW → ASSIGNED
Target Milestone: M12 → M14
setting target milestone to M14, per today's bug meeting.
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
*** Bug 17718 has been marked as a duplicate of this bug. ***
Assignee: cathleen → dbragg
we need to return a proper error code for long filename
mac - 32 chars
win - 150 chars?
unix - ?
Keywords: pp
Fixed.  Now windows is 128, Mac is 31 and Unix is 1024.  
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Any check like this should go into nsInstallFile instead, I think
Changing "AddSubcomponent" to "addFile" in Summary to reflect new API naming.
Summary: [PP]AddSubcomponent: Long file names (32 chars) not supported → [PP]addFile: Long file names (32 chars) not supported
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

Summary: [PP]addFile: Long file names (32 chars) not supported → [PP]addFile: Long file names (32 chars) not correctly handled
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.
Resetting target field for missed milestones
Target Milestone: M14 → ---
Did this ever get checked-in?
Keywords: nsbeta1, patch
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?
Whiteboard: [xpibug]
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9
Keywords: nsbeta1, patch, ppnsbeta1+
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.
sr=mscott
Target Milestone: mozilla0.9 → mozilla0.8.1
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
Build: 2001-03-09-11-trunk(MAC)

We correctly cancel out of the script.  No file is installed.  Marking Verified!
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.