19174 - Canonify does not handle UNC file paths.

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[rbs]

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" );
    nsFileSpecHelpers::NativeToUnix(mPath);
#endif
...


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
203
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()
00868cce()

Comment 1

[Suresh Duddi (gone)]

mmh! I dont think we thought of that case. Dougt ? are you owner of file spec
code.

Comment 2

[Doug Turner (:dougt)]

is that a trick question??  :-)

This will have to wait for the nsIFile.  I will make sure that this case works.

Comment 3

[Sean Richardson]

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:
   file://%5|/xryten/EV/apache/htdocs/mozilla/testcases/long/mysql.manual.html
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.

Comment 4

[Sean Richardson]

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
file:////Kryten/EV/apache/htdocs/mozilla/testcases/long/mysql.manual.html
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'

Comment 5

[Doug Turner (:dougt)]

crash is such a strong work.  Setting title.

Canonify() in nsFileSpecWin sucks as it does not handle UNC file paths.

Comment 6

[Doug Turner (:dougt)]

will be fixed by 22047

Comment 7

[Doug Turner (:dougt)]

marking as fixed.  once our branch lands you will be able to call
InitWithPath() and pass a unc path.

Comment 8

[Sean Richardson]

*** Bug 28378 has been marked as a duplicate of this bug. ***

Comment 9

[Sean Richardson]

*** Bug 28378 has been marked as a duplicate of this bug. ***

Comment 10

[Sean Richardson]

*** Bug 28378 has been marked as a duplicate of this bug. ***

Comment 11

[Sean Richardson]

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

Comment 12

[Doug Turner (:dougt)]

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.

Comment 13

[Andreas Otte]

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
path.

Comment 14

[Doug Turner (:dougt)]

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.

Comment 15

[don]

Move to M16 ...

Comment 16

[Braden]

Just a note to point to bug 32997, which seems like it may be a general
(platform-agnostic) case of this bug.

Comment 17

[Andreas Otte]

Attachment: patch to get the urlparser working with unc paths

Comment 18

[Andreas Otte]

only for XP_PC I should add ...

Comment 19

[Andreas Otte]

fix to better handle unc paths on XP_PC in the urlparser checked in

Comment 20

[verah (gone)]

Reassigning for Don

Comment 21

[Stuart Parmenter]

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.

Comment 22

[verah (gone)]

I'm just the messenger. Back to Don.

Comment 23

[don]

Bill, can you check this out later?

Comment 24

[don]

Move to M21 target milestone.

Comment 25

[Dawn Endico]

dp is no longer @netscape.com. changing qa contact to default for this product

Comment 26

[Bill Law]

It's been fixed for a while now.

Comment 27

[Stephan Niemz]

See bugs 56923 and bug 66194. Is this really fixed?

Comment 28

[benc]

+verifyme, testcase - I think those are releated, but different problems. 

UNC's (in general) still are not handled in a polished way.

Comment 29

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old