[Handycam]

In SP11, I can finally add my page to BBEdit's prefs, and that app preview fine now.

However, I still cannot preview in Dreamweaver 8.02. I get a web page that reads:

Cannot Load Address

Stopped loading <file:///POLIWHIRL/Users/Shared/WORK/409%20CANAL%20STREET/1989%20409%20canal%20web/html/contact.html>: file doesn’t exist

[Forrest]

And I take it you verified that's the proper location of that file?

[Handycam]

Yes, of course. And I also tried moving the file to the HD root and previewing it from there, similar result.

[Len Case]

Is there really a directory called "POLYWHIRL" in the root of your drive or is that the name of the volume?

[Forrest]

If you open the file from the Finder, directly into OW, do you get the same error?

[Handycam]

Originally Posted by Forrest

If you open the file from the Finder, directly into OW, do you get the same error?

No, it works fine. I can also open the html in BBEdit and preview it from there no problem.

[Handycam]

Originally Posted by Len Case

Is there really a directory called "POLYWHIRL" in the root of your drive or is that the name of the volume?

It's the root volume name (and the machine name). All my macs are named after Pokemon :D .

[Forrest]

Your volume name shouldn't be displaying. It should just be:
file:///Users/Shared/...

What causes that I don't know, sorry.

[Handycam]

Originally Posted by Forrest

Your volume name shouldn't be displaying. It should just be:
file:///Users/Shared/...

When I open the file via File>Open, it display the correct path as you show.

When I preview the file in Safari, it also shows the correct path.

So, for some reason, the path is getting munged when sent from DW to OW but not in other browsers.

[Ken Case]

Prior to Mac OS X, file URLs on the Mac always had the volume name as the first component of their path.

With Mac OS X (which is now based on UNIX), Apple standardized on the convention of using the UNIX path (just as file URLs worked on the NeXT platform, where the web was invented). Of course, many older applications still use the older file URL format, so most web browsers have to be prepared to accept either format.

This is currently broken in OmniWeb 5.5, because the code we were using to detect this in OmniWeb 5.1 is no longer being used. (It's part of the code we retired when switching to WebKit.)

Thanks for pointing out the issue!