Closed Bug 344671 Opened 18 years ago Closed 13 years ago

extensions.ini should use relative paths

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: lohphat, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Currently an entry in extensions.ini is absolute:
Extension1=D:\profiles\username\Application Data\Mozilla\Firefox\Profiles\6aoztvqw.default\extensions\{9c9c8cff-c707-48b9-b81e-6fceeb4ce43f}

It should be relative as user profiles can be moved around as sysadmis move home dirs around.  The path should be constructed using the environment variable %USERPROFILE% which would render the above entry as:

Extension1=%USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\6aoztvqw.default\extensions\{9c9c8cff-c707-48b9-b81e-6fceeb4ce43f}



Reproducible: Always

Steps to Reproduce:
see above
Actual Results:  
see above

Expected Results:  
see above
It is not cross platform friendly to use OS specific env variables such as %USERPROFILE% though we may be able to do something similar to what done in extensions.cache. If the paths change then the extensions.ini should be updated to reflect this change... does it do this for you? Also, bug 337053 is somewhat similar and if this were to change as requested in this bug report it would affect how that bug is addressed.
Then how does Firefox know to place the user profiles in "C:\Documents and Settings\[username]\Application Data\Mozilla\Firefox" without being platform specific?  If it's not pulling it from an env string it's also not pulling it from its ass.  How does it know this OS path naming context?

At some point apps need to understand realtive paths.   Welcome to CompSci 101.

If the linux build understands the difference between "/home/~userID" and "/mnt/hda0p1/user/home/userID" then so it can for win32.

Storing abosulute paths in reference to user data in config files is ALWAYS a BadThing[tm].  User profiles WILL change absolutie paths as the userbase grows and volumes have to be balanced and migrated. End of story.

Why do we have to re-hash these basic sysad issues again and again?  Do I have to go over null pointers and buffer overflow concepts again too?
All I stated is that using OS specific env vars is not cross platform friendly. There are people that use the same profile with multiple OS's and we regenerate this file when this info changes. I also didn't state we wouldn't fix this... my point is that if we did change this it would be in a cross platform manner. Is that ok with you?

So... without being a smart alec please answer these questions:
If the paths change then the extensions.ini should be updated to reflect this change... does it do this for you?
and in addition
What specific problem are you experiencing that this would fix?
Ask around moz.org, I'm known as a bitter smart ass -- I've earned it. ;-)

The simple case is that win32 defaults to "C:\Documents and Settings" for the user profiles (homedirs), but you can change the registery settings on a per user basis (and via DFS mouts if you want to get picky) so that you can move the uer profile anywhere, in this case "D:\profiles\".

If you add extentions before the move, they break after the move becasue the absolute path to the extension code in the .ini file has moved, thus breaking the extension.

All I'm saying is that if you're able to refer to the FF user files off a relative path of the user's profile in the first place, you can do that for the extension reference data.
(In reply to comment #4)
> If you add extentions before the move, they break after the move becasue the
> absolute path to the extension code in the .ini file has moved, thus breaking
> the extension.
So, in response to the question of

(from comment #1 and #3)
> If the paths change then the extensions.ini should be updated to reflect this
> change... does it do this for you?
So, it doesn't do this for you???

Also, in comment #3 I stated we might be able to use the same method as we use in extensions.cache. I don't recall why bsmedberg used full paths in extensions.ini and the only case I know of where it does break is bug 337053.
The statement about fixing this in the same manner as extensions.cache was actually from comment #1
"Detecting when the paths change" sounds like a messy reactive hack.  

Why can't any FF config item simply use relative paths when the base path per OS is predtermined once at runtime already?  There has to be a place in the XP code that 1) determines platform and 2) determines the base path for all future FF config references be it prefs.js or bookmarks.htm or what have you.  It is that string which simply needs to be prepended to references to extensions.ini entries.
*sigh* Could you please answer the question I had in comment #3. Why do I need to know this? Because if it did in fact break then I would make this a higher priority to fix. If it doesn't there are other bugs where functionality is broken that I consider more important.
*groan*  Yes, if you want to do a messy hack then YES: if the paths change extensions.ini should update the paths, but hen you have to add messy code to detect this because when the profile moves you won't know easily.  FF will just start and the extension code won't be found.  But oddly enough, prefs.js and bookmarks.htm and everything else was found. Huh.

Now will you answer MY question and explain to me how FF knows where the current user profile is in the first place and why this can't be used as the base path for a relative path entry in extensions.ini instead.
I don't know why you think that I prefer absolute paths... I asked the questions so I can prioritize this as stated in comment #5. Also, I have thought about changing this to use relative paths in the past but I have other bugs to fix that involve broken functionality.

In regards to your question I believe the following is the starting point regarding the profile dir (found from a quick lxr search)... it is irrelevant though since I already stated several times that we may be able to change this to use relative paths in the same manner as is done with extensions.cache.
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsAppDirectoryServiceDefs.h#100

In regards to my question, I'll go ahead and test it myself once I have the time to do so.
Confirming since it is a valid request.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Would it be possible that these configuration paths are relative and valid across platforms. What I mean is that I have a dual boot system and want to access my mail and calendar from both. Having absolute path like 'C:\.......' makes that hard. (build lot of soft-links in linux is how I manage. What I'd like is to be able to soft-link the .mozilla-thunderbird dir in home to relevant one in windows and have it work. 

Well atleast something which makes it possible to have your data accesible from both systems.
(In reply to comment #14)
> Would it be possible that these configuration paths are relative and valid
> across platforms. What I mean is that I have a dual boot system and want to
> access my mail and calendar from both. Having absolute path like 'C:\.......'
> makes that hard. (build lot of soft-links in linux is how I manage. What I'd
> like is to be able to soft-link the .mozilla-thunderbird dir in home to
> relevant one in windows and have it work. 
> 
> Well atleast something which makes it possible to have your data accesible from
> both systems.
When paths change the file is automatically regenerated so having your data accessible from both is already the case.
Product: Firefox → Toolkit
does bug 274046 fit in, which had been duped to Bug 350027?
There isn't any need to fix this, when the add-ons move we automatically detect and correct extensions.ini.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
Why you have those paths in extensions.ini at all, if they obviously could be retrieved from elsewhere?
Flags: needinfo?(dtownsend+bugmail)
(In reply to Ulf Zibis from comment #21)
> Why you have those paths in extensions.ini at all, if they obviously could
> be retrieved from elsewhere?

The other places they are stored would be more expensive to read at startup than extensions.ini
Flags: needinfo?(dtownsend+bugmail)
(In reply to Dave Townsend (:Mossop) from comment #22)
> The other places they are stored would be more expensive to read at startup
> than extensions.ini

Much thanks for your answer, so it seems, extensions.ini is a kind of cache.
As already mentioned in bug 952757 I'm wondering if this information should better be located in TB's cache location.
Also I'm wondering about the file extension "ini", as this is known for *defining* config files, manually editable in case of need/emergency.

If those paths in extensions.ini were relative, the benefit of startup boost would also be effective in case of:
kb.mozillazine.org/Sharing_a_profile_between_Windows_and_Linux
You need to log in before you can comment on or make changes to this bug.