Closed Bug 11701 Opened 25 years ago Closed 24 years ago

Product does not run if slash in folder path

Categories

(Core :: XPConnect, defect, P2)

PowerPC
Mac System 8.5
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: davidm)

References

Details

(Keywords: crash)

Attachments

(2 files)

If there is a slash anywhere in your file path, from your hard drive to the
folder containing the application, apprunner autoregistration fails and the
product crashes on launch.

Note: this is related to bug 3690, but is intended specifically to track slash-
in-path problems on MacOS.

Note that the registry uses NSPR file routines for the registry file, and the
problem steps from conversions between Mac and UNIX-style paths. These problems
are best solved by moving to use nsFileSpec. Using nsFileSpec would also
eliminate 255-char limits on file paths that NSPR has, and allow us to more
easily set file type and creator information for the registry file (see
bug 6181).
Assignee: dp → dveditz
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
The registry code no longer uses NSPR, this should be fixed
How did this bug ever get closed? The product still does not run if you have a
slash anywhere in the folder path; now, XPT files fail to get loaded.
How did this bug ever get closed? The product still does not run if you have a

slash anywhere in the folder path; now, XPT files fail to get loaded.
Assignee: dveditz → sfraser
Status: REOPENED → NEW
Resolution: FIXED → ---
Assign to self, clear resolution
Component: XPCOM Registry → XPConnect
XPConnect component. We need to change XPT file loading to use nsFileSpec for
performance reasons anyway.
Target Milestone: M12
Simon -- I'm setting milestone to M12
QA Contact: dp → elig
This might work now. Eli, can you test?
Sure; will be back on Thurs. and can check then.
Using the 1999102708 Mac OS build, this appears to work.

Specifically, using a previously installed build with an existing profile, the
full path to the apprunner executable was:

	Mac/OS : netscape5/mac-M11 : apprunner

Apprunner did not crash on launch (but crashed 20 seconds later while laying out
a particular page. ;)
Is that later crash reproducible? Does it go away if you remove the slash from
teh folder path? Come on QA, let's have some real testing here!  :)
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Eli tells me that the slash in folder path does not break anything that is not
otehrwise broken. Marking this bug fixed.
[haven't been ignoring this bug --- just holding off until have 15 minutes to
give a more thorough verification. In the interim, have been using a boot volume
named "Mac/OS" and Seamonkey hasn't given any problems.]
Status: RESOLVED → REOPENED
This is weird.

Using today's build and an existing profile, I can rename my hard drive to
_anything_ and it'll launch fine, unless it contains a backslash (\), in which
case Apprunner displays the splash screen, and then freezes (not a crash) with an
empty menu bar. However, this was not reproducible on sfraser's system using a
debug build.

I then went ahead and deleted my Mozilla Registry and relaunched, at which point
Seamonkey froze on the Mozilla splash screen.

Note that all of these freezes are happening in some kind of loop around scod
BFAF 0002.

Thus, re-opening.
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen of this bug.
sfraser, please let me know if you'd like me to explore further on the

reproduction. Or, just barge into my cubicle at any point and give it a shot.
Priority: P3 → P2
Summary: Product does not run if slash in folder path → [CRASH]Product does not run if slash in folder path
I'm adding the key phrase CRASH (even though it's a freeze state) and setting
the priority to P2 - it seems important enough to keep in the M12 timeframe.
Severity: normal → critical
Target Milestone: M12 → M14
Eli, please state whether you were testing the commercial or mozilla build, and
test both. I still can't reproduce this in a debug mozilla build.
Reproduced using a disk name of "\", and the 1999120208 Commercial build on Mac
OS.

Will check Mozilla build next...
Also seeing this on the Mozilla build of the same date.

Not sure why it's not appearing on your Debug build; please feel empowered to
poke around in my cube on the Mac (it's the one to the left of the iMac) if you
can stand the mess.
Status: REOPENED → ASSIGNED
Summary: [CRASH]Product does not run if slash in folder path → [CRASH]Product does not run if backslash in folder path
OK, I'm an idiot. I can reproduce this; I was renaming my system disk, not the
disk on which Mozilla was.
Here's a diff that fixes the problem.

Index: nsResourceProtocolHandler.cpp
===================================================================
RCS file: /cvsroot/mozilla/netwerk/protocol/resource/src/
nsResourceProtocolHandler.cpp,v
retrieving revision 1.20
diff -r1.20 nsResourceProtocolHandler.cpp
33a34
> #include "nsEscape.h"
256,257c257,259
<     resourceBase = nsCRT::strdup(1+(const char *)netscapePath);
<
---
>     //resourceBase = nsCRT::strdup(1+(const char *)netscapePath);
>     resourceBase = nsEscape(1+(const char *)netscapePath, url_Path);
>


The problem was that the URL parser would convert backslashes to forwrd slashes,
so we'd try to open 'foo/:bar.xul' instead of 'foo\:bar.xul'. The solution is to
escape the resource base part of the path before constructing the url.

Can someone review, please.
Two points:
- The resource protocol is about to go away as soon as I can switch over to
res:. However there might be a similar bug lurking there.

- I don't think putting the escape here is the right thing. The real bug is that
nsStdURL should be doing escaping and isn't, and nsFileURL (part of nsFileSpec)
shouldn't exist, and (a correctly implemented version of) nsStdURL should
replace it.

However, if this gets around the crash for now, you can check it in. But
reassign the bug to me so that I can fix it for good later.
No, I'm an idiot. I didn't check installation vs. system volume, and specify it
in the bug report, so of course you didn't know. ;)
Assignee: sfraser → warren
Status: ASSIGNED → NEW
Warren, I'm reassigning this to you. This isn't a blocker, so I have not checked
in that fix.
cc'ing andreas
ReplaceMess in nsStdURL converts every \ in the path component into / until it
hits # or ? or ;. If you put an \ into your harddrivename you loose at the
moment. This conversion is done for windows users to help them to move the
windows/dos path delimiter \ to / in case they forgot to do it manually. It is
done unconditionally. Maybe this has to be moved outside of nsStdURL. This
conversion also happens in nsWebShell.cpp for file-URLs that have a missing
file:/// and is ifdefed #XP_PC.
adding myself to cc list; I got burned by this problem or a related one...
(wasting a lot of time :-( )
What I saw was that if my installer directory contained a '/', the install
wouldn't even start downloading.

Does anyone on this bug have any ideas if what I'm seeing is a duplicate of this
bug or is actually a different bug?
Kathy,
The issue you allude to is separate and only pertains to the standalone
installer. See comments in bug 18482.
This will also bite you if you have any slash in a filepath you want to access
with an URL. I think there is a bigger, more general issue here, dealing with
special URL-specific chars in filenames (or drivenames) when converting to an
URL and back.
Assignee: warren → andreas.otte
Andreas, can you take this one? Thanks.
Fixing this for moving through nsDirectoryViewer should be relativly easy.
Directorys and filenames could be escaped with the rules for filenames, so every
/ (and maybe \) in a file- or directoryname would be escaped (along with ;? and
#) and would not change the semantics of the URL as it happens here.

A complete URL of this kind typed into the location bar is an entirely different
thing. I'm not sure it is possible to handle this right every time.
partial fix in ANDREAS_URL_BRANCH
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
Keywords: beta1
Putting on PDT+ radar for beta1.  Need to stop the crash.
Whiteboard: [PDT+]
Can someone with a mac look at this again, this should at least be partially
fixed when \ is in the diskname or in the path. / in filenames should work when
accessed through file:///... navigating with the Directory viewer.
Summary: [CRASH]Product does not run if backslash in folder path → Product does not run if backslash in folder path
I'm marking this one fixed to get a verification
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
doesn't work if '/' is in path; reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
changed summary from backslash to slash
Summary: Product does not run if backslash in folder path → Product does not run if slash in folder path
The fix is now in, gordon could you take a look if this works now on the Mac?
False alarm: fix is not in, needs some more investigation.
Simply escaping filenames ( and including / ) will not help, this collides with
ftp which returns directorys with a trailing /. This has to be investigated much
further, no simple fix here. I see no other choice but to move this to M15. PDT?
Maybe ftp should delete the trailing slash before appending to the nsIFile. It 
knows that that slash isn't part of the file name.
This problem with ftp is already happening in
netwerk/streamconv/converters/nsFTPDirListingConv.cpp. Sometimes a trailing / is
appended, sometimes the directory is identified by the trailing /. I tried it
against a UNIX type server and removed the trailing /. I could then enter
directorys although / in filenames in nsDirectoryViewer were escaped. 

I suggest we change the converter for every ftp server type so that the trailing
/ is removed before handing it to nsDirectoryViewer. How about opening a bug
against ftp/streamconv and let this bug depend on it. We can not escaoe the / in
filenames unless this is fixed. CCing Judson Valeski.
hang on a sec. slashes indicating dir is quite standard and changing this will 
have some pretty bad ripple affects. Maybe this is a nsIFile issue. I think the 
mac dirs/filenames should be escaped before necko/uri parsing ever sees them. 
Mac's a special case for these chars.
To fix bug 17964 we already escape filenames read from
application/http-index-format (problem with # being interpreted in urlcontext).

A name in this structure should not contain a /, be it a normal directoryname or
a filename because this will also be misinterpreted by the urlparser if not
escaped. 

There are other means to mark something as a directory (and
application/http-index-format contains that information), I don't think we need
an extra / for that. I don't want to change / being used as a dir separator,
just the opposite, I want to use it only for that in URLpath context. Then I can
simply escape it when encoutered as part of the real file/directoryname and
don't have to worry if this could also be a dir separator.
Whiteboard: [PDT+] → [PDT+] (2/25) depends on some changes to nsFTPDirListingConv and someone with a mac to help me testing
now that the changes to nsFTPDirListingConv.cpp are in, the escaping rules for /
can again be changed
Whiteboard: [PDT+] (2/25) depends on some changes to nsFTPDirListingConv and someone with a mac to help me testing → [PDT+] (2/25) depends on someone with a mac to help me testing
After testing with Gordon I think there is a lot more to this than I originally
thought. I have some ideas, but without a mac I see no way to fix this myself.
Any taker for this bug?
 
Reassigning to myself until we can find a new owner.

Cathy: Can you take this on?
Don: Got any free mac programmers?
Assignee: andreas.otte → warren
Status: REOPENED → NEW
warren do you want me to take this bug?
=> davidm
Assignee: warren → davidm
Whiteboard: [PDT+] (2/25) depends on someone with a mac to help me testing → [PDT+]
I think this bug depends on bug 28784 and/or bug 29341. For example: in the
webshell (convertFileToURL) the handling of mac-paths is completly missing.
The bug is in nsStdUrl which isn't converting the path correctly. It should 
unhex and then swap ( not replace) / with :. I don't know about the webshell 
routine. I don't think we allow the typing in of native mac paths. 
Whiteboard: [PDT+] → [PDT+] have fix which is off to be reviewed
fix checked in. You will get some asserts in debug builds( they are harmless 
warning about the potential of passing in a unix rather than native path). I 
tried volume names with / and \ and " " and everything seemed to work ok.
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → FIXED
davidm: Have you checked if you can load files in directorys with / in them
while navigating to these directorys with the directory viewer? Does it work?
Verification on commercial build is blocked by Bugsplat bug #386309.
Whiteboard: [PDT+] have fix which is off to be reviewed → [PDT+] verification blocked by bugsplat bug #386309
I pulled down the commercial bits from this afternoon (2nd build of the day) and 
put a '/' in the parent folder and was able to launch the product.
[Wrote bug #31281, "Mac builds crash on launch if * in volume name", to avoid
morphing this bug.]
Using yesterday's PM build, I'm still seeing a hang on launch with a slash in 
folder name. (bug #386309).

I could just use a Mozilla build to verify this bug, but that lessens the value 
of the verification in finding other potential issues. So, verification remains 
on hold.
What is bug #386309? Looks like a typo. If you're still seeing this, reopen this 
bug.
Depends on: 31359
It's Bugsplat.
Removing PDT+ to request reconsideration of need to verify for beta.
Verification is now blocked by 31408.

Note the non-PDT+ bug 21381, "Mac builds crash on launch if * in volume name"

Whiteboard: [PDT+] verification blocked by bugsplat bug #386309 → verification blocked by bug #31408.
Doh, typo. 31281, not 21381.
This looks fixed using the 5.2.00 AM commercial Mac OS build. Specifically, 
after:
	- naming the boot volume (which was also the volume containing Netscape 6) 
to things like "\", "/", "\|/" and other forms of droll ASCII art like "\\||\\||/
/".
	- Doing the exact same to the directory containing Netscape 6.

---

Kat, Simon was wondering if the Mac OS version Netscape 6 is being tested by 
International on systems in which the hard drive (or folder containing Netscape 
6) contains double-byte characters. Might you know whether this is the case?

Thanks!
Status: RESOLVED → VERIFIED
Eli, Netscape6 Beta 1 started OK from Japanese named folders
including those which contain names using 0x5c (backslash) or
slash. 
I did this all on MacOS US with Japanese file or folder names.
blee or cwang, can you make sure that this works OK on 
Japanese Mac OS, too?
Thanks, Kat!
When tried in MacOS 9 JA, beta 1 & 5/3/00 M16 blds launched fine with Japanese 
(including forward and back slash) named folder and HDD.
clearing whiteboard.
Whiteboard: verification blocked by bug #31408.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: