Separate installs inappropriately share nssckbi.dll

RESOLVED DUPLICATE of bug 176501

Status

P4
normal
RESOLVED DUPLICATE of bug 176501
18 years ago
2 years ago

People

(Reporter: selmer, Assigned: ddrinan0264)

Tracking

1.0 Branch
psm2.1
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
I have the 3/19 build installed in one directory, the 3/28 build in another.

When I went to delete the 3/28 directory, the system refused to delete its copy
of nssckbi.dll because it was in use.  Since the 3/19 build is the only one
running, it must somehow be using the nssckbi.dll from the 3/28 build.

Whatever this dll is for, we should always use the one installed with the
version we're running.

Comment 1

18 years ago
NSS
Assignee: asa → relyea
Component: Browser-General → Libraries
Product: Browser → NSS
QA Contact: doronr → sonmi
Version: other → 4.0

Comment 2

18 years ago
Hey David, we don't install this, can you work this out with the client team.
Thanks.

bob
Component: Libraries → Client Library
Product: NSS → PSM
Version: 4.0 → 2.0

Comment 3

18 years ago
I just finished backward compatibility testing of NSS on the PC (NT and Win2K),
and I did not notice any problem switching the set of dlls that I use.

Since I am neither familiar with PSM nor the whole browser installation I can
only share one problem that I had - the LD_LIBRARY_PATH was set to point to the
correct directory, which is ignored under Windows, and the PATH still pointed to
the wrong directories - which worked perfectly fine on Unix.

Comment 4

18 years ago
Reporter - doesn't this bug seem more like an install issue, in that maybe the 
registry wasn't properly updated when you installed 3/28 build in another 
folder?

Comment 5

18 years ago
Hmm, changing the component didn't change the owner. Dave, take a look at the
history.

bob
Assignee: relyea → ddrinan

Updated

18 years ago
QA Contact: sonmi → junruh
(Reporter)

Comment 6

18 years ago
junruh, if you know who should own it, please reassign.  When I filed this, I
didn't even realize this was a PSM related dll.  I have no direct knowledge of
any registry key usage or other mechanism that might explain the effect I
observed, so I don't feel qualified to reassign this bug myself.

Updated

18 years ago
Target Milestone: --- → 2.0
(Assignee)

Comment 7

18 years ago
-->p4
Priority: -- → P4

Comment 8

18 years ago
Mass reassigning target to 2.1
Target Milestone: 2.0 → 2.1

Updated

18 years ago
Keywords: nsenterprise

Comment 9

18 years ago
remove nsenterprise
Keywords: nsenterprise

Comment 10

18 years ago
Worksforme. I cannot reproduce with the 7/19 WinNT branch build.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 11

18 years ago
Verified worksforme.
Status: RESOLVED → VERIFIED

*** This bug has been marked as a duplicate of 176501 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago15 years ago
Resolution: --- → DUPLICATE

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

11 years ago
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.