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)
Tracking
()
VERIFIED
FIXED
M14
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).
Updated•25 years ago
|
Assignee: dp → dveditz
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 1•25 years ago
|
||
The registry code no longer uses NSPR, this should be fixed
Reporter | ||
Comment 2•25 years ago
|
||
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.
Reporter | ||
Comment 3•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Assignee: dveditz → sfraser
Status: REOPENED → NEW
Reporter | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Reporter | ||
Comment 4•25 years ago
|
||
Assign to self, clear resolution
Reporter | ||
Updated•25 years ago
|
Component: XPCOM Registry → XPConnect
Reporter | ||
Comment 5•25 years ago
|
||
XPConnect component. We need to change XPT file loading to use nsFileSpec for performance reasons anyway.
Updated•25 years ago
|
Target Milestone: M12
Comment 6•25 years ago
|
||
Simon -- I'm setting milestone to M12
Reporter | ||
Updated•25 years ago
|
QA Contact: dp → elig
Reporter | ||
Comment 7•25 years ago
|
||
This might work now. Eli, can you test?
Comment 8•25 years ago
|
||
Sure; will be back on Thurs. and can check then.
Comment 9•25 years ago
|
||
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. ;)
Reporter | ||
Comment 10•25 years ago
|
||
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! :)
Reporter | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 11•25 years ago
|
||
Eli tells me that the slash in folder path does not break anything that is not otehrwise broken. Marking this bug fixed.
Comment 12•25 years ago
|
||
[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.]
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
Clearing FIXED resolution due to reopen of this bug.
Comment 15•25 years ago
|
||
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.
Updated•25 years ago
|
Priority: P3 → P2
Summary: Product does not run if slash in folder path → [CRASH]Product does not run if slash in folder path
Comment 16•25 years ago
|
||
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.
Updated•25 years ago
|
Severity: normal → critical
Reporter | ||
Updated•25 years ago
|
Target Milestone: M12 → M14
Reporter | ||
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
Reproduced using a disk name of "\", and the 1999120208 Commercial build on Mac OS. Will check Mozilla build next...
Comment 19•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Status: REOPENED → ASSIGNED
Summary: [CRASH]Product does not run if slash in folder path → [CRASH]Product does not run if backslash in folder path
Reporter | ||
Comment 20•25 years ago
|
||
OK, I'm an idiot. I can reproduce this; I was renaming my system disk, not the disk on which Mozilla was.
Reporter | ||
Comment 21•25 years ago
|
||
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.
Comment 22•25 years ago
|
||
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.
Comment 23•25 years ago
|
||
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. ;)
Reporter | ||
Updated•25 years ago
|
Assignee: sfraser → warren
Status: ASSIGNED → NEW
Reporter | ||
Comment 24•25 years ago
|
||
Warren, I'm reassigning this to you. This isn't a blocker, so I have not checked in that fix.
Comment 25•25 years ago
|
||
cc'ing andreas
Comment 26•25 years ago
|
||
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.
Comment 27•25 years ago
|
||
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?
Comment 28•25 years ago
|
||
Kathy, The issue you allude to is separate and only pertains to the standalone installer. See comments in bug 18482.
Comment 29•25 years ago
|
||
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.
Updated•25 years ago
|
Assignee: warren → andreas.otte
Comment 30•25 years ago
|
||
Andreas, can you take this one? Thanks.
Comment 31•25 years ago
|
||
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.
Comment 32•25 years ago
|
||
partial fix in ANDREAS_URL_BRANCH
Comment 34•25 years ago
|
||
Putting on PDT+ radar for beta1. Need to stop the crash.
Whiteboard: [PDT+]
Comment 35•25 years ago
|
||
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.
Updated•25 years ago
|
Summary: [CRASH]Product does not run if backslash in folder path → Product does not run if backslash in folder path
Comment 36•25 years ago
|
||
I'm marking this one fixed to get a verification
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Comment 37•25 years ago
|
||
doesn't work if '/' is in path; reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 38•25 years ago
|
||
Comment 39•25 years ago
|
||
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
Comment 40•25 years ago
|
||
The fix is now in, gordon could you take a look if this works now on the Mac?
Comment 41•25 years ago
|
||
False alarm: fix is not in, needs some more investigation.
Comment 42•25 years ago
|
||
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?
Comment 43•25 years ago
|
||
Maybe ftp should delete the trailing slash before appending to the nsIFile. It knows that that slash isn't part of the file name.
Comment 44•25 years ago
|
||
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.
Comment 45•25 years ago
|
||
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.
Comment 46•25 years ago
|
||
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.
Updated•24 years ago
|
Whiteboard: [PDT+] → [PDT+] (2/25) depends on some changes to nsFTPDirListingConv and someone with a mac to help me testing
Comment 47•24 years ago
|
||
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
Comment 48•24 years ago
|
||
Comment 49•24 years ago
|
||
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?
Comment 50•24 years ago
|
||
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
Assignee | ||
Comment 51•24 years ago
|
||
warren do you want me to take this bug?
Comment 52•24 years ago
|
||
=> davidm
Assignee: warren → davidm
Whiteboard: [PDT+] (2/25) depends on someone with a mac to help me testing → [PDT+]
Comment 53•24 years ago
|
||
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.
Assignee | ||
Comment 54•24 years ago
|
||
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
Assignee | ||
Comment 55•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 56•24 years ago
|
||
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?
Comment 57•24 years ago
|
||
Verification on commercial build is blocked by Bugsplat bug #386309.
Updated•24 years ago
|
Whiteboard: [PDT+] have fix which is off to be reviewed → [PDT+] verification blocked by bugsplat bug #386309
Comment 58•24 years ago
|
||
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.
Comment 59•24 years ago
|
||
[Wrote bug #31281, "Mac builds crash on launch if * in volume name", to avoid morphing this bug.]
Comment 60•24 years ago
|
||
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.
Comment 61•24 years ago
|
||
What is bug #386309? Looks like a typo. If you're still seeing this, reopen this bug.
Comment 62•24 years ago
|
||
It's Bugsplat.
Comment 63•24 years ago
|
||
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.
Comment 64•24 years ago
|
||
Doh, typo. 31281, not 21381.
Comment 65•24 years ago
|
||
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
Comment 66•24 years ago
|
||
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?
Comment 67•24 years ago
|
||
Thanks, Kat!
Comment 68•24 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•