OK, I understand now.
I was forgetting about the silly WSOD file i/o stuff.
I think the best solution is to check for the return codes from opening the files
and allowing them to still work, rather than putting them in MOZILLA_HOME.
The first option is easier to get past the Mozilla community.
I am surprised you don't run into the same problem with the *.rdf file in
bin/chrome.
They must be opened correctly (They are created if they don't exist as well)
Thank you for your help.
I will look at this today.
Mike Kaply
IBM
Bj�rn-Willy Arntzen wrote:
> On the client ?
>
> j:\os2\Moz094\COMPONENT.REG is a common file
>
> look at this interestring i/o trace that I have created below:
>
> the file component.reg is opened in writemodus at the programlocation. Not
> the MOZILLA_HOME location, I have a rc=32 problem if it's shared.
>
> result - openmode -openflag - file
> 00 01 00A3 J:\os2\moz094\mozilla.EXE
> 00 01 21A0 J:\os2\moz094\APPPOST.FIT
> 00 01 00A3 J:\OS2\MOZ094\MOZILLA.EXE
> 00 01 00A3 J:\os2\moz094\GKGFX.DLL
> ...
> 6E 01 20A2 J:\OS2\MOZ094\component.reg
> 00 12 20A2 J:\OS2\MOZ094\component.reg <<--
> ******** here is the file opened
> 00 01 0040 J:\OS2\MOZ094\components\msgbase.xpt
> ....
> ....
>
> Now I have testet it, and found that component.reg is not 'touched', but the
> two files xpti.dat and xptitemp.dat is written to, and mozilla does a silen
> die if the two files is not writeable. Here is the last lines in a i/o trace
> before it dies:
>
> 00 01 00A3 J:\OS2\MOZ094\NSSCKBI.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\GFX_OS2.DLL
> 00 01 00A3 J:\os2\moz094\GFXRES.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\DOCSHELL.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\CAPS.DLL
> 03 01 0040 J:\OS2\MOZ094\chrome\locales\en-US\navigator.properti
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\COOKIE.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\JSDOM.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\OJI.DLL
> 00 01 00A3 J:\os2\moz094\JSJ.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\GKPLUGIN.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\MOZBRWSR.DLL
> 00 01 00A3 J:\OS2\MOZ094\COMPONENTS\APPCOMPS.DLL
>
> If I make there to files writeable mozilla works fine, but I expect a sharing
> violation when 100 users trying to write to this file.
>
> This give me two solutions:
>
> a) The xpti.dat and xptitemp.dat need to be moved to MOZILLA_HOME. I can see
> this is a compatibility problem.
> b) Mozilla handles a open-fail if the file already exists.
>
> Bj�rn-Willy
>
> Michael Kaply wrote:
>
> > This is good news.
> >
> > Those three files you mention can be precreated and placed on the client.
> > There is no need for them to be created by starting the browser.
> >
> > Could you try this?
> >
> > Thank you
> >
> > Mike Kaply
> > IBM
> >
> > Bj�rn-Willy Arntzen wrote:
> >
> > > Hello there, the workspace guy (me) has tested the latest release....
> > >
> > > The good news is that a WorkspaceOnDemand client now can run Mozilla
> > > from everywhere I want. This is very good, but I have to create a
> > > FIT-file to manage this. The file is show below.
> > >
> > > j:\os2\Moz094\MOZREGISTRY.DAT
> > > \\SERVER\D$\HOMEDIR\<USER>\Moz094\MOZREGISTRY.DAT
> > > j:\os2\Moz094\COMPONENT.REG
> > > \\SERVER\D$\HOMEDIR\<USER>\Moz094\COMPONENT.REG
> > > j:\os2\Moz094\COMPONENTS\XPTI.DAT
> > > \\SERVER\D$\HOMEDIR\<USER>\Moz094\XPTI.DAT
> > > j:\os2\Moz094\COMPONENTS\XPTITEMP.DAT
> > > \\SERVER\D$\HOMEDIR\<USER>\Moz094\XPTITEMP.DAT
> > >
> > > Even if this is working, the use of FIT files is not wanted, because a
> > > ordinary Warp Client cannot use FIT files, so if I want to run a
> > > networkinstalled (shared drive) Mozilla, the client still tries to
> > > create the following files: component.reg, xpti.dat and xptitemp.dat on
> > > the programdirectory (j:\os2\Moz094) I have set the env. variable
> > > MOZILLA_HOME to F:\Moz094 (f: is the users homedrive), and it's working
> > > fine. The profiles are placed in f:\moz094 directory.
> > >
> > > Mike K. my most wanted feature/fix is that the files component.reg,
> > > xpti.dat and xptitemp.dat is also places in the MOZILLA_HOME directory.
> > > If this could be done the public part and the private part is separeted
> > > which make a networing environment very easy....
> > >
> > > The bad news is that proxy still is so slow that it's not working. It
> > > takes 5-10 minutes to load www.vg.no. If I uses direct connection to
> > > internet, it's so fast that my hair is blowing....
> > >
> > > Could this be a bug or maybe a configuration thing ? I have checked the
> > > firewall log and there is not a error logged. Netscape 4.61 had no
> > > problem with this.
> > >
> > > Bj�rn-Willy Arntzen, KLP Incurance, Norway
> > > [EMAIL PROTECTED]
