Closed Bug 10147 Opened 26 years ago Closed 24 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: 25 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: 25 years ago24 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.

Attachment

General

Creator:
Created:
Updated:
Size: