Closed Bug 19174 Opened 21 years ago Closed 19 years ago

Canonify does not handle UNC file paths.


(Core :: XPCOM, defect, P3)






(Reporter: rbs, Assigned: law)




(Keywords: testcase)


(1 file)

With today's tree (Nov 18, 1999), the code asserts when
trying to load a file that comes from the "Network
Neighborhooh" feature of Win32. The name of the file
is in the format  "\\Server\path\file.html"
and this is apparently not recognized.

The NS_ASSERTION that is fired is indicated below:

nsFilePath::nsFilePath(const nsString& inString, PRBool inCreateDirs)
    // Make canonical and absolute.
    nsFileSpecHelpers::Canonify(mPath, inCreateDirs);
#ifdef XP_PC
    NS_ASSERTION( mPath[1] == ':', "unexpected canonical path" );

The stack trace is:
KERNEL32! bff768a4()
nsDebug::Assertion(const char * 0x004d3f68, const char * 0x004d3f58, const char
* 0x004d3f28, int 682) line 284 + 13 bytes
nsFilePath::nsFilePath(const nsString & {...}, int 0) line 682 + 46 bytes
nsFileWidget::GetFile(nsFileWidget * const 0x01f81630, nsFileSpec & {...}) line
GetFileFromFileSelector(nsIWidget * 0x00ff8b44, nsFileSpec & {...}, nsFileSpec &
{...}) line 784
nsBrowserWindow::DoFileOpen() line 798 + 23 bytes
nsBrowserWindow::DispatchMenuItem(int 40010) line 523
nsNativeBrowserWindow::DispatchMenuItem(int 40010) line 125
HandleBrowserEvent(nsGUIEvent * 0x0086fba4) line 339 + 21 bytes
nsWindow::DispatchEvent(nsWindow * const 0x00ff8b44, nsGUIEvent * 0x0086fba4,
nsEventStatus & nsEventStatus_eIgnore) line 437 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0086fba4) line 458
nsWindow::ProcessMessage(unsigned int 273, unsigned int 40010, long 0, long *
0x0086fc4c) line 2510 + 21 bytes
nsWindow::WindowProc(HWND__ * 0x000003f8, unsigned int 273, unsigned int 40010,
long 0) line 624 + 27 bytes
KERNEL32! bff7363b()
KERNEL32! bff942e7()
Assignee: dp → dougt
mmh! I dont think we thought of that case. Dougt ? are you owner of file spec
is that a trick question??  :-)

This will have to wait for the nsIFile.  I will make sure that this case works.
Summary: [CRASH] when loading a file via Network Neighborhooh → [CRASH] when loading a file via Network Neighborhood
Tried to replicate through the UI with 1999-11-17-17-M12 on WinNT.
No crash, this instead:

Steps followed:
1. Brang up the file picker dialog at File>Open File in the browser.
2. Navigated to a file on the same machine in that dialog as follows:
   chose Network Neighbourhood, chose localhost machine, chose MS-Windows
   share that represents an entire drive, chose directories until a large
   file could be selected.
3. Clicked on [Ok] in the file picker.
4. The URL file://KRYTEN/EV/apache/mozilla/testcases/long/mysql.manual.html
   appeared in the Location bar (EV is the share name for my E: drive)
   but nothing appeared in that window.
5. A new browser window launched.
6. The following appeared in its location bar:
7. After editing that URL to match the one seen in step 4 and trying again,
   the console showed the following (excerpt):
   >FindShortcut: in='file://kryten/EV/apache/htdocs/mozilla/testcases/long/
   >mysql.manual.html'  out='null'

As far as I can tell, the URL shown in step 4 is a valid way of representing
a UNC filespec as a file:// URL.

I don't know what happened to the URL in step 6, but it sure isn't right.

Tested with 1999-11-17-17-M12 nightly binary on Windows NT 4.0sp3 on small
LAN with both NetBEUI and TCP/IP bound to the NetBIOS interface and to the
ethernet adapter. (Yes, I do have read permissions for the share that is
my own E: drive!) Hope some of this detail helps.
Hmm. Trying the same thing in Communicator 4.7, the local file appears in
the Open Page dialog after picking as
\\Kryten\EV\apache\htdocs\mozilla\testcases\long\mysql.manual.html , but as
in the Location Bar - and that URL loads the file.  (The four slashes seem
counterintuitive - the file is being accessed through a network interface.)
Tried the same URL in Mozilla, and got the equivalent of the message seen on
the console in step 7 in the previous comment:
   >FindShortcut: in='file:////kryten/EV/apache/htdocs/mozilla/testcases/long/
   >mysql.manual.html'  out='null'
Summary: [CRASH] when loading a file via Network Neighborhood → Canonify does not handle UNC file paths.
Target Milestone: M14
crash is such a strong work.  Setting title.

Canonify() in nsFileSpecWin sucks as it does not handle UNC file paths.
Depends on: 22047
will be fixed by 22047
Closed: 20 years ago
Resolution: --- → FIXED
marking as fixed.  once our branch lands you will be able to call
InitWithPath() and pass a unc path.
*** Bug 28378 has been marked as a duplicate of this bug. ***
*** Bug 28378 has been marked as a duplicate of this bug. ***
*** Bug 28378 has been marked as a duplicate of this bug. ***
Attempting to open file: URL with a UNC path, either by using the File>Open File
dialog, or by pasting in a URL that works in NN 4.7, results in no page load;
if the file is specified by choosing a path through "Network Neighbourhood"
in the Win32 file picker, no URL shows in the URL bar either. REOPENing

Resolution: FIXED → ---
Assignee: dougt → andreas.otte
this sounds like a file url parsing problem as UNC paths do work.  To verify 
that there is a ls tool in xpcom/test.  reassigning.
This are some comments from bug 28378 which was marked as a duplicate of this
bug and therefor reopened this one:

> This is a real problem. When trying it on windows 2000 I got two assertions 
> from nsFileSpec.cpp.
> ###!!! ASSERTION: unexpected canonical path: 'mPath[1] == ':'', file 
> j:\mozilla\mozilla\xpcom\io\nsFileSpec.cpp, line 689
> ###!!! ASSERTION: No drive letter part!: 'original[2] == '|'', file 
> j:\mozilla\mozilla\xpcom\io\nsFileSpec.cpp, line 607
> The inString argument to nsFilePath::nsFilePath was 
> "\\Fraggel\T2BLIDER\pic15.jpg"

It seems nsFileSpec does not like the whole UNC-path in the path component. It
expects a driveletter (on XP_PC) otherwise it asserts. I don't think this is a
urlparser problem unless you want "Fraggel" as hostname and not as part of the
okay Andreas has set me straight.  The File->Open dialog uses nsFileSpecWithUI, 
not nsIFile.  The XPFE team will have to replace uses of that with nsIFile.
Assignee: andreas.otte → don
Move to M16 ...
Target Milestone: M14 → M16
Just a note to point to bug 32997, which seems like it may be a general
(platform-agnostic) case of this bug.
only for XP_PC I should add ...
fix to better handle unc paths on XP_PC in the urlparser checked in
Reassigning for Don
Assignee: don → pavlov
Target Milestone: M16 → ---
huh??  why is this assigned to me?  nsIFilePicker uses nsIFile and if people
arn't using that, then that is their problem.  I have nothing to do with
ns[I]FileSpec[WithUI]. reassigning to verah.
Assignee: pavlov → verah
I'm just the messenger. Back to Don.
Assignee: verah → don
Bill, can you check this out later?
Assignee: don → law
Target Milestone: --- → M18
Move to M21 target milestone.
Target Milestone: M18 → M21
dp is no longer changing qa contact to default for this product
QA Contact: dp → kandrot
It's been fixed for a while now.
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
See bugs 56923 and bug 66194. Is this really fixed?
+verifyme, testcase - I think those are releated, but different problems. 

UNC's (in general) still are not handled in a polished way.
Keywords: testcase, verifyme
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.