110832 - Mozilla crashes if AppData dir redirected to UNC path

Status: VERIFIED DUPLICATE of bug 162025

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Trent Mick]

A user's AppData directory on Windows can be redirected to a Network UNC path. 
A number of locations in Mozilla's file handling cannot deal with a UNC path 
resulting in Mozilla (and Komodo, see http://bugs.activestate.com/show_bug.cgi?
id=7547) crashing.

*Some* of these locations have been found and a patch is coming for those. Some 
locations, I have no idea how many, remain.

My understanding is that AppData redirection is fairly common on corporate 
networks.

Comment 1

[Trent Mick]

I *would* attach my file but everytime I try I get the error that no file was 
specified or that the file was empty (it is not empty).

Comment 2

[Ashley Bischoff (blog at handcoding.com)]

The file attachment problem you're seeing is bug 110613.

Anyhow, please try a talkback-enabled build:
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip
(as always, be sure to delete your old Mozilla directory before installing the
new one)

Then, if you get a crash, please post the Talkback ID here.
(you can get the talkback id by running <moz-dir>/bin/components/talkback.exe)

Comment 3

[timeless]

benc just loves these bugs.

Comment 4

[timeless]

.

Comment 5

[Doug Turner (:dougt)]

trent, can you attach the proposed changes now the bugzilla problems are fixed

Comment 6

[Trent Mick]

Attachment: proposed partial fix to allow UNC paths

This is just a partial fix. Komodo, for now, took the route of working around
this problem by falling back to CSIDL_LOCAL_APPDATA on Windows if CSIDL_APPDATA
was a UNC path (the presumption being that CSIDL_LOCAL_APPDATA directory is
*not* a UNC path <fingers-crossed>). Here is that Mozilla patch that Komodo is
using for that:
 http://bugs.activestate.com/Komodo/showattachment.cgi?attach_id=163
and the related Komodo bug:
 http://bugs.activestate.com/Komodo/show_bug.cgi?id=7547

Comment 7

[benc]

put link into url field.

doug, can we move this bug to P1?

Comment 8

[Doug Turner (:dougt)]

moving out.  I think that the best way to fix this bug is to remove the reliance
on nsFileSpec which doesn't have support for UNC.  There may be other UNC
related problems while nsFileSpec is still in existance.  

Comment 9

[benc]

+makingtest
If we support this, we probably have to test MacOS X as well...

Comment 10

[Andrew Hagen]

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

Comment 11

[benc]

+relnote: for Mozilla 1.0

Comment 12

[benc]

+nsenterprise: sounds like something big customers would want.

Comment 13

[benc]

-> profile manager +nsbeta1

If I understand doug's comment correctly, they are using nsFileSpec, and there
are alternatives (b/c most components don't have these problems).

Maybe we need to expand our testcases to include more LAN based filesystems.

Comment 14

[Andrew Hagen]

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

Comment 15

[Andrew Hagen]

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

Comment 16

[Andrew Hagen]

Naive question: is this a dupe of bug 100395?

Comment 17

[Ken Weaverling]

I just want to add that this bug was a show stopper at my organization for
deploying Mozilla or Netscape in our enterprise on a few thousand workstations.
We use folder redirection of the application data folder to a network share
(UNC) via a GPO (group policy object).  After much hair pulling, I came here
looking to see if this was a recorded bug and what rev may have the fix. This
one is causing me to abandon the idea of rolling out Netscape to my 12,000 users
(it's a college). 

Many other sys admins I know at other large environments use folder redirection
to UNC shares as well, so this bug will unfortunately block any consideration at
many large companies from deploying a Mozilla-based product.

So, fwiw (not much), I just voted for this bug.  I wish I could help, but I do
want to encourage people at AOL/Netscape who want to evangelize Netscape back
into corporate world, to talk to some of these companies and find out what a big
problem this one is.

Comment 18

[Denis Jedig]

Ken: Although the inability to handle UNC paths is a real handicap, you could
consider moving the Mozilla profile to the user's home directory, which is
usually a network share mapped to a local drive. Since the AppData folder is
redirected to just the very same home directory, you will just have to choose
the appropiate directory.

You will have to clear the "hidden" attribute of your appdata folder then, since
the profile manager unfortunately does not support direct entry of the profile
directory, but only browsing by click&point in a very limited dialog, where no
hidden objects are shown.

Comment 19

[Jason Wong]

anyone want to give me a pointer on where to start to get this fixed?  I
wouldn't mind doing some leg work if someone could point me to a starting point
(i'm assuming that the patch for this bug is too old to be relevant).  Is this
an easy fix that no one has to time for?  just let me know.  My organization is
chomping at the bit to push this out if it weren't for this boog.

Comment 20

[Screwtape]

I'm having exactly the same problem with WinXP. However, manually starting the 
Profile Manager and creating a profile (anywhere - local drive, UNC path, 
mapped drive) doesn't really help, as Mozilla can't find it afterwards. Here's 
the process:

1. Start the profile manager (Mozilla or Phoenix)
2. Create a new profile on the local drive.
3. Click 'Start Mozilla' (or 'Start Phoenix')
4. Everything works fine.
5. Quit.
6. Start the profile manager again.
7. No profiles are listed. :(

I suspect this is because whatever file stores the 'list of profiles' is also 
stored in %APPDATA%, as well as the profiles themselves, though I have no 
evidence of this whatsoever.

Comment 21

[Trent Mick]

[Jason Wong said:]
> anyone want to give me a pointer on where to start to get this fixed?

You could start with the attached "proposed partial fix", although I am sure 
that it is monumentally out of date (being almost a year old). I started and 
then found that fixing this bug will probably requiring digging into a lot of 
code. Basically there is a potential for failure anywhere that file paths are 
manipulated in the Mozilla code base. I don't have a feeling for how widespread 
or concentrated that is.

Comment 22

[Torben]

This is probably the same as bug 162025. I am gonna make this bug a duplicate of
that even though this is older, because most other simmilar bugs have already
been duped to that.

[e-mail], you might want to attach your patch there as well.

*** This bug has been marked as a duplicate of 162025 ***

Comment 23

[K'Trina Medina]

Verified as a dupe of bug 162025