It seems that Windows (XP?) mounts password-saved network shares "on-demand". If a profile is a network drive (which is "on-demand" mounted), when Mozilla starts the profile is lost, and another "default" profile is created using the default location (?). This means if Quick Launch enabled, the profile is "lost" with every restart of the machine (although can be recreated by deleting the newly created profile, and repointing a new profile to the network location).
this would be back end....
Assignee: ben → ccarlen
Component: Profile Manager FrontEnd → Profile Manager BackEnd
Accepting. It's gonna be a while though.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
I just got a crash which seems to be related to this when shutting down Mozilla. I got messages that error saving to share, although I was able to browse the share from Explorer). TB5337850G Does Mozilla keep certain mail/cache related file handles concat(and not reopening them if a failure occured)?
I have a similar problem, altough maybe it might warrent another bug report. Not sure. I have a profile on a network share (Samba on Linux). It works well. However, whenever I restart WinXP, if the first thing I do is start Mozilla, it shows me the profile manager and it tells me that it cannot access the path to the profile. I then shutdown Mozilla, start Windows explorer and open the path to the profile, and then open Mozilla again. This time, Mozilla finds the profile and everything works as expected; i.e. Mozilla finds the profile on the network share. Windows explorer enables the network share. It seams that Mozilla does not.
There maybe an easy way to reproduce this, just by physically disconnecting from the network before starting the Mozilla browser window ...
Regarding comment #4 I made, I just want to point out that I have the exact same problem with Quicken 2001; if I have not started Windows Explorer (WE) and switch to the network drive, Quicken 2001 complains that it cannot find the file. But after firing up WE on my network drive, Quicken opens up without a problem. So, its not necessarly a bug per say of Mozilla. Maybe Mozilla must call some API like WE to mount the network drive automatically. But it is not a problem specific to Mozilla, for sure.
*** Bug 138583 has been marked as a duplicate of this bug. ***
Rewording Summary to describe bug more specifically. The old Summary meant (almost) nothing.
Summary: profile kept on network mounted drive → WinXP can't find Profile on network mounted drive
Same situation as Hans Deragon has here, only on windows98se. (and equal to de duplicate bug #138583 mentioned above) Mozilla checks on startup which profiles are available and which aren't. I Agree the problem with network shares is not mozilla's fault, but it would be nice for mozilla to resolve. What IS a mozilla bug is that the check is only done once, at startup (of Mozilla). Once the network share has been enabled mozilla should accept the selected profile, not keep saying the profile isn't available. Mozilla should check when I click a certain profile each and every time. I suggest moving the check from startup of mozilla to the point where the users selects the profile. All profiles are allways displayed, including the unavailable ones, so I don't see any problem in moving the actual moment of detection. But it does solve part of the problem. (restarting mozilla is no longer nescesary. When (if) mozilla in the future will activate the nescesary network connections the proposed moment of detection will also prevent unneeded network-connection to be established. Establishing all network connections just to check wheter a profile is available might be considered unwanted. Why would you check the availability of all profiles, but do nothing with the results untill a profile is selected when just checking the single selected profile will suffice? Another related problem you would accidently solve with this is that when you store a profile on a removable drive, you don't want the profile being accessed when the disk isn't in the drive. For example: accessing a Iomega Jaz when there is no disk in the drive _will_ cause a BSOD. I don't select a profile on Jaz when there is no disk inserted because I know that means trouble, but mozilla will check, no matter what. I've 'solved' this by using an empty disk when normally I would use no disk. It's not an pretty solution, but it works. It's just that it's an unnescesary problem. (And yes, I'm aware that I'm probably the only person in the world storing mozilla profiles on jaz :) but the same problem might exist for other media or network drives asking for password, etc.) The problem isn't life-threatning, but the solution is so very simple and only has advantages that I'm of the opinion that it should be fixed.
fwiw I don't think anyone formerly associated with this bug is still here.
Assignee: ccarlen → nobody
Status: ASSIGNED → NEW
QA Contact: ktrina → profile-manager-backend
I just noticed with Firefox 4.6b5 that this bug seems to have gone away. I don't have to restart Firefox after the drive (where profile is located) is mounted. I did quick tests on what happens if the profile directory goes away while Firefox is running. Well, as i surfed around i kept getting error messages in the Error Console (these were related to mozIStorageError & mozIStorageStatementWrapper). Some older versions would simply stop responding... Definitely an improvement. However after i mounted the profile drive (with Firefox still running), the error messages didn't stop coming until i restarted Firefox. I would say this bug is fixed....
WFM per comment 12
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.