(if i haven't found the right component, please change as appropriate) Build: 2002091014 Background: - I store my e-mail (among other things) on an encrypted "virtual" drive using Jetico BestCrypt, this drive appears to windows as a normal removable disk drive. - I have only ONE profile and it is named "Default", it is stored locally in "E:\Profiles\Default" (E: being the mount point for my (e)ncrypted disk) Problem: When I attempt to launch Mozilla after a reboot, the Profile Manager is displayed. I only have one account so this shouldn't come up, but when i click on "Default" and then press OK it says the folder for this profile could not be found or something to that effect, i'll follow up with the actual error message if that is not accurate enough as i'm typing in moz right now and it would require a reboot. The folder hasn't moved, it's still in the same location it always is. If I delete "Default" profile, and then create a new Default, and point it to my E:\Profiles directory, it finds \Profiles\Default and loads up everything as it should have originally. After this, no matter how many times I completely exit Mozilla, everything will work normally when I launch Mozilla. That is, until I reboot again. Then I must go over the process again. For some reason it seems to be "forgetting" the path to my profile. Whether this is due to it being on a "removable" (to Windows) drive, or whether it is due to using the non default directory is unknown.
This is more likely back end....
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
Have tracked this down to the fact quicklaunch is getting loaded slightly before windows auto-mounts the drive. It would seem quicklaunch is verifying profile directories, and because the drive with the profiles is not mounted at the instant quicklaunch loads, it never finds it. The profile selection dialog should verify the profile directory, and not rely on incorrect information from quicklaunch.
> Have tracked this down to the fact quicklaunch is getting loaded slightly before windows auto-mounts the drive. Ah, thanks for the debugging :-) Sounds like what is happening is that the profile registry is read only at the initial startup when the drive is not online and then, when the profile location is actually needed, the profile location is not refreshed as it should be now that the drive is online.
Status: UNCONFIRMED → NEW
Ever confirmed: true
changing summary ...
Summary: moz wont find profile in non-standard(default) directory after reboot → if quicklaunch loaded before profiles drive mounted PM wont find profiles
QuickLaunch may cause this problem, but it's not the only thing: * having profile on a removable ZIP drive * launching mozilla at boot-time, not using quicklaunch So, removing quicklaunch from summary.
Status: NEW → ASSIGNED
Summary: if quicklaunch loaded before profiles drive mounted PM wont find profiles → if mozilla launched before profiles drive mounted PM wont find profiles
Target Milestone: --- → mozilla1.3alpha
Technically it's not a zip drive, but essentially it's the same theory behind it. And as I mentioned, I am using quicklaunch. Quicklaunch loads at boot time and manages to load just prior to windows getting the drive mounted. Then when I do attempt to launch Mozilla, the PM is displayed with my sole profile listed, but if I select the profile and attempt to proceed it gives some error that the profile could not be found. PM is not verifying the profile location when it is displayed. QL seems to be attempting to verify profiles when it loads instead. In general you've got the correct idea, just a couple points seemed a bit muddled. Hopefully this clears things up.
Target Milestone: mozilla1.3alpha → mozilla1.3beta
Setting to milestone that's not passed.
Target Milestone: mozilla1.3beta → mozilla1.6alpha
From Mozilla 1.3 onwards this is actually two bugs-in-one: 1. Unavailable Profiles - such as those on removable media - are still shown in the "Available Profiles" list. 2. Available Profiles are checked only at Mozilla startup. Before Mozilla 1.3 came out we couldn't Switch Profiles so this wan't an issue!
This seems to be a duplicate of bug #123184 (See that bug for more comments) This bug doesn't seem to be XP specific.
conrad no longer uses. duping
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 123184
You need to log in before you can comment on or make changes to this bug.