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)
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.
Updated•26 years ago
|
Target Milestone: M12
Comment 1•26 years ago
|
||
The error code is wrong, but it definitly is a bug to install a file with a name
longer than 31 chars on mac.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Bulk move of XPInstall (component to be deleted) bugs to Installer: XPInstall
Engine
we need to return a proper error code for long filename
mac - 32 chars
win - 150 chars?
unix - ?
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
Comment 8•25 years ago
|
||
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 → ---
Comment 9•25 years ago
|
||
Any check like this should go into nsInstallFile instead, I think
Reporter | ||
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
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
Assignee | ||
Comment 12•24 years ago
|
||
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.
Assignee | ||
Comment 13•24 years ago
|
||
Comment 15•24 years ago
|
||
Did this ever get checked-in?
Assignee | ||
Comment 16•24 years ago
|
||
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?
Updated•24 years ago
|
Whiteboard: [xpibug]
Assignee | ||
Comment 18•24 years ago
|
||
Comment 19•24 years ago
|
||
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•24 years ago
|
||
sr=mscott
Assignee | ||
Comment 21•24 years ago
|
||
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 22•24 years ago
|
||
Build: 2001-03-09-11-trunk(MAC)
We correctly cancel out of the script. No file is installed. Marking Verified!
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•