Closed Bug 337053 Opened 19 years ago Closed 15 years ago

extensions wont load if unix user is renamed

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 344671

People

(Reporter: m4rccd, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.2) Gecko/Debian-1.5.dfsg+1.5.0.2-3 Firefox/1.5.0.2 Build Identifier: I if rename my current user to another login name with usermod, my extensions wont load. This include moving my home directory. Permisions are set right to user:group 755. Doing a grep -Ri "marccd" * |grep -vi binary insidide my ~/.mozilla/firefox returns a lot of explicit literal /home/marccd (my old user home). I am pretty certain this might be the problem. My new user home is /home/marc. I believe this problem might as well affect themes. (I dont use them though). I reported it here instead of the Debian Bugzilla because I am sure it is a Firefox problem, and not a Debian problem. Anyways, I am not sure about an internal solution for Firefox, it could check for ~ and set an internal variable such as $HOME. But I believe the HOME dir should be independent. I could either s/\/home\/marccd/\/home\/marc/g on all of those, or do a symlink. Reproducible: Always
Does touching all the directories in the profile's extensions directory work after you rename?
>Does touching all the directories in the profile's extensions directory work after you rename? I dont understand your question, but doing this: (Changing every "home/marccd" string to "home/marc" in all files recursively in ~/.mozilla/firefox/) find . -type f -print0 | xargs -0 sed -i -e 's/home\/marccd/home\/marc/g' Works
Extension information is stored in three files and only one of these files - extensions.ini - contains full paths. This file is dynamically generated and will be updated if the last modified time - stored in the extensions.cache - on an extension's directory has changed. By using touch you can change the last modified time of all installed extension's directories which are located in the profile's extensions directory.
Marc, another way you can check is by disabling then enabling an extension. This should regenerate the paths as well. Benjamin, what do you think about storing relative paths or using a key in extensions.ini?
Regardint the cache's variables: Ah, did not know that, and I assure you 99% of users dont either. I believe it should be automatic anyways, not having to go and touch some hideous file. As Firefox moves onto a wider, more homogenous non-geek user-base, things should be made to just-work :). I don't know how this problem affects Darwin or Win, but I am sure most users in those plattform dont want to deal with something like this. Anyways, I dont know if doing a simple check of ~ (in POSIX, or the HOME environment variable in Win) against extensions.cache's value on startup is a performance hog, but it would be a solution to this problem. Anyways, thanks for telling me about it :)
Marc, no problem - I didn't expect you or anyone else to know. From the distinct lack of bug reports on this issue I am 99% sure that the majority of users don't run into this problem. What I'd like to have confirmed by you though is whether using touch on the directories after you rename makes the extensions work?
marc@athlon:~/.mozilla/firefox/marc> ls -l extensions.cache -rw-r--r-- 1 marc marc 2412 2006-05-01 00:46 extensions.cache marc@athlon:~/.mozilla/firefox/marc> touch extensions.cache && ls -l extensions.cache -rw-r--r-- 1 marc marc 2412 2006-05-07 14:38 extensions.cache Touching extensions.cache does not achieve anything. My extensions are not loaded. However, if I disable and then enable one extension, and restart Firefox, all my extensions are loaded.
Right, touching extensions.cache wouldn't help... what needed to be touched are the extension's directories in the profile's extensions directory per comment #1. On win iirc a rename of a user doesn't rename the user's directory so this shouldn't affect win which is probably why this hasn't been reported previously... not sure about Mac OS X.
In case it isn't clear why I'd like you to verify this... this will assist in verifying there isn't anything else happening besides the absolute paths in extensions.ini causing this problem for you.
rob, we could add the profile path to CheckCompatibility (nsAppRunner.cpp).
I'm wondering if it wouldn't make sense to verify the paths in extensions.ini instead of the profile path which should take care of bug 299652 as well or would that be too much of a perf impact? We should be able to remove the extensions.ini on the first path found that no longer exists and then let the EM regenerate it. The EM may need a bit of work but I think it does the right thing when in this condition to support this already.
That might work... we could also then cache the list of dirs in nsXREDirProvider so that we didn't have to re-parse the INI file each time we make a call to GetFiles.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 350027
Product: Firefox → Toolkit
No longer blocks: 350027
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.