581518 - Profiles with absolute locations get nuked with Firefox 4 after downgrade/upgrade procedure

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100722 Minefield/4.0b3pre

Due to some magic, Firefox 3.6.x converts all clear text paths inside the profiles.ini into nsIFile.persistentDescriptor instances. That only happens when you i.e. have the above given extension installed in Minefield before. With the downgrade all paths get converted, and performing an upgrade to Minefield  afterward those entries can't be read and the profiles.ini gets nuked. Only the profiles under the default location will remain.

Steps:
1. Create some profiles outside of the default location, i.e. another partition
2. Start one of those profiles with a recent Minefield build
3. Install GrafxBot and restart Minefield
4. Check the profiles.ini => everything is ok
5. Close Minefield and start Firefox 3.6.x with the same profile
6. Check the profiles.ini => all paths have been converted
7. Close Firefox 3.6.x
8. Start Minefield again

With step 8 you will see that all of the profiles stored at other locations have been nuked from the profiles.ini file. Only the ones at the default location remain.

The question is what's that special on that extension that it causes this behavior. There is no way for me to reproduce without that extension installed.

For users without knowledge of the details it will be a dataloss, even the profile will remain. Not sure if it is enough for the dataloss keyword. Feel free to remove it again.

Comment 1

[Aaron Train [:aaronmt]]

and a result of this causes bug 581482

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Ok, please drop the part with the extension! It's not necessary. It's even simpler:

1. Start Minefield with a fresh profile
2. Restart Minefield with the same profile
3. Start a Firefox 3.6.x build

Comment 3

[Dave Townsend [:mossop]]

Looks like this is only a problem switching from branch to trunk as branch supports trunk's form of persistent descriptor.

Trunk lost branch's form with bug 571193

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I can also see this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7

As given by the build id it is quite some days before the first commit of the patch on bug 571193. Are you sure that this is the reason?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #4)
> I can also see this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
> 
> As given by the build id it is quite some days before the first commit of the
> patch on bug 571193. Are you sure that this is the reason?

Sorry, that was the wrong build id. And it's really caused by bug 571193. Beta 2 is working as expected. We simply converted the profiles.ini between clear paths and persistentDescriptor instances.

This regression makes it really hard for QA to run tests with Minefield on our own machine. Because any start of Minefield will nuke our profiles.ini file.

Comment 6

[Benjamin Smedberg]

In particular, the old behavior of SetPersistentDescriptor is what we need back: http://hg.mozilla.org/mozilla-central/annotate/5372b453a52e/xpcom/io/nsLocalFileOSX.mm#l1463

Comment 7

[Josh Aas]

Attachment: fix v1.0

I haven't tested this yet but it compiles and probably works. Will request review when I've tested.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #7)
> Created attachment 460115 [details] [diff] [review]
> fix v1.0
> 
> I haven't tested this yet but it compiles and probably works. Will request
> review when I've tested.

Tested with a debug build and the patch applied. Works fine for me. Thanks for this quick turnaround Josh!

Comment 9

[Benoit Girard (:BenWa)]

The patch looks good. Are we sure we don't need the NS_OBJC_BEGIN_TRY_ABORT_BLOCK_NSRESULT?

Comment 10

[Josh Aas]

The APIs being used here aren't going to throw Obj-C exceptions.

Comment 11

[Josh Aas]

pushed to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/3559a37d183f

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Looks good with todays Minefield build. Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b3pre) Gecko/20100726 Minefield/4.0b3pre