Closed Bug 733436 Opened 12 years ago Closed 12 years ago

Add-ons won't install when the profile is located on a FAT32 drive

Categories

(Toolkit :: Add-ons Manager, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15

People

(Reporter: mkaply, Assigned: mossop)

References

Details

Attachments

(1 file)

We're hosting our profile on a USB stick formatted with FAT32.

We've found that add-ons will not install on this profile.

The errors we got were:

Error: ERROR addons.xpi: Failure moving /Volumes/Data 1/.se/browser/profile/extensions/staged/crashme@ted.mielczarek.org/components/._crashme.manifest to /Volumes/Data 1/.se/browser/profile/extensions/crashme@ted.mielczarek.org/components
Source File: resource://gre/modules/XPIProvider.jsm
Line: 250

Error: ERROR addons.xpi: Failed to move entry /Volumes/Data 1/.se/browser/profile/extensions/staged/crashme@ted.mielczarek.org/components/._crashme.manifest: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isDirectory]"  nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: <TOP_LEVEL> :: line 243"  data: no]
Source File: resource://gre/modules/XPIProvider.jsm
Line: 243

Error: ERROR addons.xpi: Failure moving /Volumes/Data 1/.se/browser/profile/extensions/staged/crashme@ted.mielczarek.org/components to /Volumes/Data 1/.se/browser/profile/extensions/crashme@ted.mielczarek.org
Source File: resource://gre/modules/XPIProvider.jsm
Line: 250

Error: ERROR addons.xpi: Failed to move entry /Volumes/Data 1/.se/browser/profile/extensions/staged/crashme@ted.mielczarek.org/components: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isDirectory]"  nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: <TOP_LEVEL> :: line 243"  data: no]
Source File: resource://gre/modules/XPIProvider.jsm
Line: 243

Error: ERROR addons.xpi: Failure moving /Volumes/Data 1/.se/browser/profile/extensions/staged/crashme@ted.mielczarek.org to /Volumes/Data 1/.se/browser/profile/extensions
Source File: resource://gre/modules/XPIProvider.jsm
Line: 250

Error: ERROR addons.xpi: Failed to install staged add-on crashme@ted.mielczarek.org in app-profile: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsIFile.isDirectory]"  nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame :: resource://gre/modules/XPIProvider.jsm :: <TOP_LEVEL> :: line 243"  data: no]
Source File: resource://gre/modules/XPIProvider.jsm
Line: 243

After some debugging, it was determined that on Mac, resource forks are created automatically for all the files in the zip when it is unzipped. These files begin with ._

If all of these files are removed before you restart Firefox, the add-on installs correctly.

Per Mossop:

Well XPIProvider is seeing them in the directory and attempting to do something with them. Specifically nsIFile.isDirectory is claiming they don't exist (even though it found it throughnsIFile.directoryEntries) . I'd have to debug in to find out exactly why
We could potentially workaround this by ignoring anything starting "._", but it'd be interesting to debug an isDirectory call for one of these files to see specifically what is going on.
I discovered that even if I manage to get the add-on installed by deleting some files at install, the add-on then can't be deleted because some of the ._ files get recreated.
Having finally got a chance to test this myself I'm not seeing the same behaviour here. On my mac (10.7) with a profile on a FAT USB stick, no additional files are created when extracting from an extension I tested (I used Context Search as an example). The extension installed and uninstalled just fine.
I'm using 10.6.8 - not sure if that makes a difference.

Context Search doesn't have unpack:true set.

To see this, you need an add-on that is unpacked.
I enabled extensions.alwaysUnpack first
Assignee: nobody → dtownsend+bugmail
Status: NEW → ASSIGNED
Try run for e3462c4100e1 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=e3462c4100e1
Results (out of 57 total builds):
    success: 36
    warnings: 21
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dtownsend@mozilla.com-e3462c4100e1
Attached patch patch rev 1Splinter Review
To summarise (in a long-winded fashion), OSX sometimes stores resource forks for files. On FAT which doesn't support forks as such it stores the data in what is called the AppleDouble format, which means the data file remains as-is and the resource data goes in a file prefixed with "._". OSX automatically handles keeping the resource files stuck with their data counterparts so when we go through the list of files and move the data file, OSX automatically moves the resource file, then when we come to move that (because we work from a cached list of files in the directory) it is gone and things fall over.

In this patch I sort the list of files to ensure that we encounter the main file first (meaning that if there is a resource file it gets correctly moved with its data) and then if a file has already vanished when we get to it then we just continue on ignoring that error.

Unfortunately I don't think we can build an automated test for this case. I've tested it manually though and it works for me.
Attachment #623177 - Flags: review?(bmcbride)
Comment on attachment 623177 [details] [diff] [review]
patch rev 1

Review of attachment 623177 [details] [diff] [review]:
-----------------------------------------------------------------

(In reply to Dave Townsend (:Mossop) from comment #7)
> Unfortunately I don't think we can build an automated test for this case.
> I've tested it manually though and it works for me.

Heh, yea, I wondered about that.

Should we be doing this for the staging directory/processFileChanges too?

::: toolkit/mozapps/extensions/XPIProvider.jsm
@@ +1341,3 @@
>    try {
> +    let entry;
> +    while (entry = entries.nextFile)

Can this really throw? Because there are places where we don't have this in a try/finally block.
Attachment #623177 - Flags: review?(bmcbride) → review+
(In reply to Blair McBride (:Unfocused) from comment #8)
> Comment on attachment 623177 [details] [diff] [review]
> patch rev 1
> 
> Review of attachment 623177 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> (In reply to Dave Townsend (:Mossop) from comment #7)
> > Unfortunately I don't think we can build an automated test for this case.
> > I've tested it manually though and it works for me.
> 
> Heh, yea, I wondered about that.
> 
> Should we be doing this for the staging directory/processFileChanges too?

I looked over those carefully this morning and I don't believe there is any problem there. The code will see the resource files as normal XPI files, attempt to load a manifest from them and fail and then just skip over them.

> ::: toolkit/mozapps/extensions/XPIProvider.jsm
> @@ +1341,3 @@
> >    try {
> > +    let entry;
> > +    while (entry = entries.nextFile)
> 
> Can this really throw? Because there are places where we don't have this in
> a try/finally block.

Don't think so, removed the try...catch.

https://hg.mozilla.org/integration/mozilla-inbound/rev/95def0230d0c
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/95def0230d0c
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
I just got around to retesting this (sorry) and it works much better, but still fails.

In the case of the crashme extension (http://code.google.com/p/crashme/) all the files are copied properly including forks except one file - crashme@ted.mielczark.org.json (that's not a file in the XPI, I guess that's related to staging?)

The error is slightly different though

Error: ERROR addons.manager: Exception calling provider startup: [Exception... "Component returned failure code: 0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST) [nsILocalFile.isDirectory]"  nsresult: "0x80520006 (NS_ERROR_FILE_TARGET_DOES_NOT_EXIST)"  location: "JS frame :: resource:///modules/XPIProvider.jsm :: <TOP_LEVEL> :: line 1970"  data: no]
Source File: resource:///modules/XPIProvider.jsm
Line: 1970

Do you want me to open a new bug?
(In reply to Michael Kaply (mkaply) from comment #11)
> Do you want me to open a new bug?

Yes, please.
Opened bug 795873
Depends on: 795873
You need to log in before you can comment on or make changes to this bug.