Shame on you guys for putting the following code into nsFileChannel.cpp: 93 beard 1.31 #ifdef XP_MAC 94 brendan 1.55 nsFilePath filePath(nsUnescape((char*)(const char*)fileString)); 95 mSpec = filePath; 96 97 // Don't assume we actually created a good file spec 98 FSSpec theSpec = mSpec.GetFSSpec(); 99 if (!theSpec.name[0]) 100 { 101 NS_ERROR("failed to create a file spec"); 102 103 // Since we didn't actually create the file spec 104 // we return an error 105 return NS_ERROR_MALFORMED_URI; 106 } 107 beard 1.31 #else 108 brendan 1.55 nsFilePath filePath(nsUnescape((char*)(const char*)fileString)); 109 mSpec = filePath; 110 beard 1.31 #endif This Mac-specific code belongs in nsFilePath (or nsFileSpec), not in nsFileChannel.cpp which is xp. Let's get it out of here, and into someplace that will benefit all callers. Warren

I never touched this code except to auto-expand tabs, or strip trailing whitespace on lines, or some such. Wish blame could "see through" that.... /be

I was just unlucky enough to hit an even more severe problem with this code tonight. I tried to load the url file://Y|/foo.txt which ended up coming through here. The GetFilePath call (a few lines above the code I gave) returned "/foo.txt" which is the correct path portion of the url. This passed through nsUnescape unscathed, but then nsFilePath made an object whose internal path pointed to y:\mozilla\dist\win32_d.obj\bin\foo.txt!!! Somehow it'sthinking that the leading slash in "/foo.txt" isn't significant to designate the root of the file system and taking the current (process) directory instead. This could be because it's a forward slash instead of a backslash, but it's supposed to be a forward slash coming from nsIURL::GetFilePath. That's URL syntax. There's obviously an impedence mismatch here between nsIURL and nsFilepath, and possibly a bug in nsFilePath too.

Sorry, I was merely fixing some bugs, I don't own this code. Clearly non-XP the code should not be here. I'll be glad to make suggestions, but I shouldn't own this bug.

Doug own filepath and stuff. Scott collins might be able to help.

moving to m14. I will fix this when nsIFile is done.

This is critical. file: URLs just don't work if they're not relative to the program directory. It's blocking my ability to get the jar: and res: protocols working.

Putting on PDT- radar. This is porkjockey work.

This is a bogus fix. It looks like this area of code does checking for existance of the url for mac only. Warren, when I create a nsFileChannel, and I pass a bad nsIURI to the Init method, when should the error be discovered?

No one is touching nsFileSpec. See if this is still a problem once nsIFile lands.

will be fixed by 22047

fixed by nsIFile.