WinXP can't find Profile on network mounted drive



17 years ago
3 years ago


(Reporter: gaborliptak, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)




17 years ago
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.
Ever confirmed: true
Target Milestone: --- → Future

Comment 3

17 years ago
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).


Does Mozilla keep certain mail/cache related file handles concat(and not
reopening them if a failure occured)?

Comment 4

17 years ago
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.

Comment 5

17 years ago
There maybe an easy way to reproduce this, just by physically disconnecting from
the network before starting the Mozilla browser window ...

Comment 6

17 years ago
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

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.

Comment 7

16 years ago
*** Bug 138583 has been marked as a duplicate of this bug. ***

Comment 8

16 years ago
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


16 years ago
Blocks: 170539

Comment 9

16 years ago
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.


16 years ago
Blocks: 101953
No longer blocks: 170539


11 years ago
Duplicate of this bug: 170676

Comment 11

9 years ago
fwiw I don't think anyone formerly associated with this bug is still here.
Assignee: ccarlen → nobody
QA Contact: ktrina → profile-manager-backend

Comment 12

9 years ago
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....

Comment 13

8 years ago
WFM per comment 12
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME


3 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.