123184 - WinXP can't find Profile on network mounted drive

Status: RESOLVED WORKSFORME

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Gabor Liptak]

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).

Comment 1

[Boris Zbarsky [:bzbarsky]]

this would be back end....

Comment 2

[Conrad Carlen (not reading bugmail)]

Accepting. It's gonna be a while though.

Comment 3

[Gábor Lipták]

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)?

Comment 4

[Hans Deragon]

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

[Gábor Lipták]

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

Comment 6

[Hans Deragon]

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.

Comment 7

[SunOS]

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

Comment 8

[guanxi]

Rewording Summary to describe bug more specifically.  The old Summary meant
(almost) nothing.

Comment 9

[Roland Witvoet]

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.

Comment 11

[Wayne Mery (:wsmwk)]

fwiw I don't think anyone formerly associated with this bug is still here.

Comment 12

[Mudi Obada]

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

[Wayne Mery (:wsmwk)]

WFM per comment 12