[PP]Can't run apprunner in Mac if directory has "/" in it

RESOLVED FIXED in M10

Status

()

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

People

(Reporter: Paul MacQuiddy, Assigned: dveditz)

Tracking

Trunk
PowerPC
Mac System 8.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
If you change the seamonkey folder name (such netscape5-mac-M7) to include a
forward slash (such as 'seamonkey6/18') then apprunner will not run. Removing
the forward slash and you can run again. I'm guessing it is a registry problem.

The forward slash is a legal character in MacOS, apparently, as I'm allowed to
enter it when changing the directory name.

Updated

19 years ago
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: M8

Comment 1

19 years ago
This is a known bug. I have a fix on hand. Since it was a api change, we are
checking it into M8.

Updated

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

Comment 2

19 years ago
This one should be fixed with xpcom using nsIFileSpec.

Updated

19 years ago
Summary: Can't run apprunner in Mac if directory has "/" in it → [PP]Can't run apprunner in Mac if directory has "/" in it
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 3

19 years ago
Same behavior with 6/23 builds. Re-opening.

Updated

19 years ago
Status: REOPENED → ASSIGNED

Updated

19 years ago
Resolution: FIXED → ---

Comment 4

19 years ago
Could you describe behaviour.
(Reporter)

Comment 5

19 years ago
Sure.

Double-click on apprunner. App begins to launch, then quits after 2-3 seconds.
No crash, just doesn't do anything. Take forward slash out of folder name and
apprunner starts up no problem.
(Reporter)

Comment 6

19 years ago
This is still failing on 7/8 builds. I will release note it, assuming it will
not be fixed more M8.

Updated

19 years ago
Target Milestone: M8 → M9

Comment 7

19 years ago
Yes paul. Moving to m9.
dp, is this something I should be looking into?

Updated

19 years ago
Assignee: dp → dveditz
Status: ASSIGNED → NEW

Comment 9

19 years ago
Yes. I just talked to simon and he says that the first instance of fail is the
PR_OpenFile() that libreg does. I dont know how you are going to solve this. Is
using filespec an option for libreg. I didn't think so.

Anyway I will let you figure it out.
Actually that would be pretty easy -- originally the registry used stdio calls
to open the registry, taking purely native paths not the
pseudo-cross-platform-not-really NSPR paths. Those calls are all in working
#ifdefs because we build libreg "standalone" (without NSPR) for the 4.x
installs.

McMullen switched libreg to nspr because it supposedly ran faster, but
"working" is better than not-working faster. If I add the buffering maybe that
would make up for it.

Updated

19 years ago
Target Milestone: M9 → M10

Comment 11

19 years ago
dveditz just started looking at this. moving to m10.
(Reporter)

Comment 12

19 years ago
this causes a crash in M9 milestone builds, FWIW
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
The registry code now uses native pathnames, avoiding slash confusion.

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.