component.reg uses absolute path names

RESOLVED FIXED in M10

Status

()

Core
XPCOM
P3
normal
RESOLVED FIXED
19 years ago
10 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: Suresh Duddi (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
When starting Apprunner from a UNC after Apprunner has been started from the
same directory on the machine itself (i.e., when starting the same Apprunner
installation from a different directory), I get a deluge of messages along the
lines of:


**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/prefwind.dll) FA
ILED with error: error 0
**************************************************
*** Registering html library
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************
**************************************************
nsComponentManager: Load(D:/INTERNET/WEB/MOZILLA/BIN/components/raptorhtml.dll)
FAILED with error: error 0
**************************************************


This is very bad. I should be able to run Apprunner from any path without
deleting the registry file.
(Reporter)

Updated

19 years ago
OS: other → Windows NT
Hardware: Other → PC
(Reporter)

Comment 1

19 years ago
See also a comment by chofmann in bug 7916.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M8
(Assignee)

Comment 2

19 years ago
I just ran two instance of apprunner from the same directory on my NT  machine
and that worked.

Could you let me know what build you are using and something more about UNC
(Assignee)

Comment 3

19 years ago
I read bug# 7916

I think moving the component.reg along with the binary in the <exedir> should
have fixed this.

Let me know if this aint the case. This got fixed a week ago atleast.
(Reporter)

Comment 4

19 years ago
The problem was poorly described. My apologies.

Steps to reproduce:
   Unzip mozilla archive into a folder, say c:\mozilla\
   Run apprunner from there.
   Share the folder.
   Assuming your machine is called "foo", and the share is called "bar",
    go to "\\foo\bar". i.e., using "Network Neighborhood", go to the
    share containing apprunner.exe.
   Run apprunner from there.

UNC stands for Universal Naming Convention, i.e., a network path in the form
   \\machine\share\path\file

The build I used is Sunday's. Deleting the component.reg file solved the problem
(or rather, it precipitated bug 8684...).

Can you reproduce the problem using the steps above?
(Assignee)

Comment 5

19 years ago
Ah ha! I know why you are seeing this. And I am sad that this is by design. :-(

Of course, we have to change the design to fix this. We will.

The problem is that component.reg is with the exe and all the component dlls are
registered with full pathnames. When run from two different paths pointing to
the same installation, the component registry is still pointing to the old
pathnames.

Fix would be to store relative pathnames in the component registry. Would it be
ok if I change the summary of the bug appropriately.
(Reporter)

Updated

19 years ago
Summary: Starting Apprunner from UNC doesn't work → component.reg uses absolute path names
(Assignee)

Updated

19 years ago
Target Milestone: M8 → M10
(Assignee)

Comment 6

19 years ago
Steve/Bhuvan can you help implement relativeness in nsFileSpec. Then I can use
it to implement relative pathnames in the registry.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 7

19 years ago
Component registry uses relative path.

Updated

10 years ago
Component: XPCOM Registry → XPCOM
QA Contact: dp → xpcom
You need to log in before you can comment on or make changes to this bug.