simulator fails to create dir on Windows with NS_ERROR_FILE_NAME_TOO_LONG #78

mykmelez opened this Issue Nov 8, 2012 · 4 comments


None yet

2 participants

Mozilla member

The Windows API limits file path lengths to 260 characters, and at least one person reported in this blog comment that Simulator failed to create a directory because its path was too long:

Errore: ERROR addons.xpi: extractFiles: failed to create target directory for extraction file = C:\Documents and Settings\Administrator\Dati applicazioni\Mozilla\Firefox\Profiles\xxxxxx.default\extensions\staged\\resources\r2d2b2g\data\profile\webapps\marketplace-dev\cache\\telefonica\media\img\mkt: [Exception... "Component returned failure code: 0x80520011 (NS_ERROR_FILE_NAME_TOO_LONG) [nsIFile.create]” nsresult: “0×80520011 (NS_ERROR_FILE_NAME_TOO_LONG)” location: “JS frame :: resource:///modules/XPIProvider.jsm :: extractFiles :: line 1105″ data: no]
File sorgente: resource:///modules/XPIProvider.jsm
Riga: 1105

A long-term solution to this problem would be to copy the simulator profile outside of the addon directory, but that requires some rearchitecting. In the short-term, we might be able to mitigate the problem by moving the profile directory to the top-level of the addon directory.

We could also make the addon ID shorter to save a few characters, although existing users who install a version with the new ID will then have to uninstall the old version manually.

Mozilla member

I confirmed this by creating a user on Windows XP with a 20-character-long username: longaccountnametests. That's the longest possible username on Windows XP, and while it probably isn't very common to have usernames that long, it probably is common to have usernames that are 13 characters long, i.e. "Administrator".

I asked the rocketeers how to package profile into the top level of the XPI directory hierarchy to work around this limitation, and @erikvold said:

Maybe we should add a flag for this, but adding a top level directory doesn't seem easy, afaict you can unpack the xpi and re-zip it with the new directory, or use the --templatedir flag.

Getting a uri for the directory with Addon.getResourceURI , using require('self').id, should work.


This is bug 811560 for the sdk

Mozilla member

This is fixed by commit 16533d9.

@erikvold I used --templatedir to implement this, but I've cc:ed myself to that SDK bug so I can reimplement this functionality using whatever support that bug adds, given that --templatedir is something of a hack (I also have to put copies of install.rdf and bootstrap.js in that directory in order for it to work--although cfx only complains about a missing install.rdf).

@mykmelez mykmelez closed this Nov 14, 2012
Mozilla member

@digitarald Important! I previously showed you how you can activate the SDK and use cfx directly instead of make run. With this change, you need to specify an additional option to cfx when doing so:

cfx run --templatedir template/

(from within the addon/ directory)

You'll also need to rebuild the profile via make prosthesis before using either make run or cfx.

@potch @tofumatt for that last bit of info. Make sure you make prosthesis after pulling this change!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment