Last Comment Bug 636268 - reduce length of generated paths
: reduce length of generated paths
Product: Add-on SDK
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Windows XP
P1 normal with 2 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
: 665555 687049 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-02-23 14:23 PST by Hernán Rodriguez Colmeiro (:peregrino)
Modified: 2015-03-31 01:19 PDT (History)
8 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Hernán Rodriguez Colmeiro (:peregrino) 2011-02-23 14:23:20 PST
If you set a long name to your addon (more than 15chars for example),
it seems that some intermediate file of the installation process is
being created with a name longer than the maximum supported length on some windows systems. Thus the installation process fails when the zip extractor tries to handle that:

Warning: WARN addons.xpi: Failed to install: [Exception... "Component
returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND)
[nsIZipReader.extract]"  nsresult: "0x80520012
(NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
resource://gre/modules/XPIProvider.jsm :: extractFiles :: line 865"
data: no]
Source File: resource://gre/modules/XPIProvider.jsm
Line: 865

Also this leads to some issues with having deep folder structures, like you can see here:

Error: ERROR addons.xpi: extractFiles: failed to create target
directory for extraction file = C:\Documents and
[Exception... "Component returned failure code: 0x80520011
(NS_ERROR_FILE_NAME_TOO_LONG) [nsIFile.create]"  nsresult: "0x80520011
(NS_ERROR_FILE_NAME_TOO_LONG)"  location: "JS frame ::
resource://gre/modules/XPIProvider.jsm :: extractFiles :: line 849"
data: no]
Source File: resource://gre/modules/XPIProvider.jsm
Line: 849
Comment 1 User image Myk Melez [:myk] [@mykmelez] 2011-03-31 13:24:45 PDT
I think Brian has some plans to fix this.
Comment 2 User image Brian Warner [:warner :bwarner] 2011-05-20 15:17:50 PDT
yeah. The current XPI layout unpacks the XPI into a directory named $JID, and the XPI has top-level directories named $PKGNAME-lib/ or $PKGNAME-data/ , and then the .js filenames go under that. The windows max path length is 256 characters long, and includes all of that plus the full path to the profile's "extensions/" directory. There's a lot of detail in the create_jid() comment in python-lib/cuddlefish/ (

We removed the cryptographic JID from 1.0b5, and the replacement is slightly shorter (27 characters for an 80-bit random JID, while the cryptographic one was 40 characters long), improving the situation a little bit.

The main fix for this will be bug 638742, which is to stop unpacking the XPI completely. When that is done, none of the pathnames will matter: they'll all stay safely trapped inside the zipfile. At that point, the name of the XPI file and the length of the profile directory will be the only issues.

Secondary fixes, which honestly are more likely to happen *after* bug 638742 if at all, is to drop the 1:1:1 mapping of source filename to zipfile/unpacked name to URI. The names used inside the zipfile (or in the unpacked filenames) could be simple unique counters, as long as they contain the right contents. We want to keep the real filenames inside the URIs, so that errors and exception tracebacks are easy to relate to source code, but with arbitrarily complex resource: protocol mapping functions (currently in harness.js), we could map URI=fullpath -> zipname=1 -> sourcefile=fullpath .

Until then, yeah, I guess the best advice is to use shorter package names, use a new non-cryptographic JID, or install Firefox higher up the directory tree so the profile dir's absolute path is shorter.
Comment 3 User image Myk Melez [:myk] [@mykmelez] 2011-06-20 16:21:45 PDT
*** Bug 665555 has been marked as a duplicate of this bug. ***
Comment 4 User image Wes Kocher (:KWierso) 2011-08-17 12:36:10 PDT
WONTFIXing in favor of bug 638742.
Comment 5 User image Mardeg 2011-10-01 17:41:17 PDT
*** Bug 687049 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.