252905 - Need a way to trigger re-registration for all profiles when new components are installed

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Brian Ryner (not reading)]

Since Firefox has moved the component registry to the profile directory, you can
no longer just touch .autoreg or run 'firefox -register' after adding components
-- the former will only re-register for the first profile to run, assuming it
has write access to .autoreg, and the latter will not do anything useful at all.

What we need instead is for .autoreg, or an equivalent file, to have its
timestamp compared against the profile's compreg.dat on each run, and if it's
more recent, re-register components.

Comment 1

[Brian Ryner (not reading)]

Attachment: patch

This does what I described above for .autoreg.

Comment 2

[Darin Fisher]

*** Bug 253119 has been marked as a duplicate of this bug. ***

Comment 3

[Darin Fisher]

Comment on attachment 154342 [details] [diff] [review]
patch

>Index: build/nsXPComInit.cpp

>+    PRInt64 compregModTime, autoregModTime;
>+    compregFile->GetLastModifiedTime(&compregModTime);
>+    file->GetLastModifiedTime(&autoregModTime);
>+
>+    return LL_CMP(autoregModTime, >, compregModTime);
> }

you're assuming that GetLastModifiedTime never fails, but that
assumption is based on the behavior of ReadPersistentRegistry
and GetLastModifiedTime itself.  might be it better to at least
add an ASSERTION that the return value is a success code for
each of these method calls?  i wouldn't object to testing the
return values and returning PR_TRUE if an error occurs.


>+        compregFile->SetLastModifiedTime(PR_Now() / 1000);

i think you need to use the LL_DIV macro here.


r=darin with at least this last problem fixed.

Comment 4

[Doug Turner (:dougt)]

why did you move the component registry into the profile directory?  That never
has been supported by XPCOM.  How do you select the profile prior to xpcom
initalization?

Comment 5

[Benjamin Smedberg]

> why did you move the component registry into the profile directory?  That 
never
> has been supported by XPCOM.  How do you select the profile prior to xpcom
> initalization?

Doug, this was the discussion regarding semi-single-profile that we had months 
ago. We select the profile by reading an INI file before starting XPCOM, and 
pass a directory service provider to the XPCOM startup routine.

Comment 6

[Doug Turner (:dougt)]

got it. ;-)

how about simply adding some code to touch the ini file instead of changing xpcom?

Comment 7

[Brian Ryner (not reading)]

(In reply to comment #6)
> how about simply adding some code to touch the ini file instead of changing xpcom?

The ini file lists the profiles for a particular user, and therefore lives in
the per-user data directory (i.e. ~/.mozilla/firefox) and is not global.

Comment 8

[Brian Ryner (not reading)]

checked in on trunk and branch

Comment 9

[Darin Fisher]

> how about simply adding some code to touch the ini file instead of changing xpcom?

we also have to support the -profile switch, which can be used to select a
profile  (given the full path to a profile) that is not necessarily listed in
profiles.ini

Comment 10

[Walter K.]

(In reply to comment #3)
> (From update of attachment 154342 [details] [diff] [review])
...
> 
> >+        compregFile->SetLastModifiedTime(PR_Now() / 1000);
> 
> i think you need to use the LL_DIV macro here.
> 
> 
> r=darin with at least this last problem fixed.
> 

Should that be fixed? As far as I can see, that's not in the branch checkin
(rev. 1.194.2.1.4.2).