Can you please provide the actual wikitext tried, and an exact diff showing your change to the code? Make sure also that this isn't simply a cached
page issue.

file://C:\DATA\WPDOC\XTO\TOOLS\HTML\dir2223.htm

file:///D:/Homepage/tg/40.html

file://C:\DATA\WPDOC\XTO\TOOLS\HTML\mylocalfiles.htm

The patch as described here
[http://meta.wikimedia.org/wiki/Meta:FAQ#Is_it_somehow_possible_to_use_a_FILE_URI-Qualifier_for_local_intranets_e.g._.5Bfile:.2F.2Flocalhost.2FC:_C-Drive.5D_.3F
Link to local files]
--[[User:WikiAdmin|Thomas Gries]] 08:46, 1 Oct 2004 (CEST)

The URL "file:///D:/Homepage/tg/40.html" seems to work fine here. (Internet Explorer 6 on Windows XP SP2.) The other two are invalid as they use
backslashes, so they cut off at the drive letter.

Brion,

it is not working (WinXP SP2, neither Netscape 7.1 or IE6.0 do).

The behaviour is as follows:

• The Link is shown in the status line, i.e. the browser _could_ get the URI,

but the double-click does _not_ perform opening the file.

• remaining link of _the_ page (see my bugzilla posting 07:12 UTC)

"[http://meta.wikipedia ...." is (patch applied) not rendered as a link, but
with escaped(!) characters:

(cut&paste from my screen:)

... file:.2F.2Flocalhost.2FC:_C-Drive.5D_.3F' class='external'
title="http://meta.wikimedia.org/wiki/Meta:FAQ#Is it somehow possible to use a
FILE URI-Qualifier for local intranets e.g. .5Bfile:.2F.2Flocalhost.2FC:
C-Drive.5D .3F">Link to local files

• I shall supply you with screenshots (a half day later).
• Could be a problem o fhe "class" and "text" tags in the <a href anchors ?

It seems to be a strange error. As written above, XP2, IE6.0 and NETSCAPE 7.1
are affected.

Before you go any further, please test that your browsers support using file: links from an http: source. This may be disabled by default due to
general security issues with file: URLs and malicious scripting vulnerabilities.

I've been unable to get any of these working in raw HTML served via HTTP:
<p><a href="file:///c:\foo.htm">a</a></p>

<p><a href="file:///c:/foo.htm">b</a></p>

<p><a href="file:///c|/foo.htm">c</a></p>

All the URLs work when pasted into the URL bar in both IE6 and Firefox 1.0PR, but clicking has no effect in either browser when the source file is
served via HTTP from my test server. When the file is saved to disk and loaded, all links work in both browsers.

Brion,

I can *confirm* your findings regarding your statement, that the file:/// links appear to work only for accessing files from a
locally saved html file what I *only* tested before launching the #614 .

However, when I set in my IE6.0 (now on Windows2000) the security setting "Miscellaneous -> Access data source across domains =
enable" (I am not sure, if this one influences the file:/// behaviour), and after restarting IE:

nothing has changed.

Secondly,
I also need to investigate the other reported problem (a further non-file link on that page is not-rendered as link and escaped).
So please keep the bugreport open - I'll try to locate both reasons and to better show with screenshots, what is or what is not
going wrong, and: from a fresh installation of perhaps the recent 1.3.5 (my bug report is related to 1.3.2 as correctly indicated).

Does anyone know, why three slashes are needed ? Isn't that another (small) bug
? Tom

By the way, I clarified the item of FILE-URIs on Meta-FAQ (full link: see in the
bug posting), as every major current Windows browser seems to suppress
delivery/linking of local files, if the file:// link resides on a
server-delivered html page. (Only file:// links on locally saved html pages are
treated by most browser.)

I came to the conclusion, that no reason exists why file:// links should be
enabled in a wiki software: the wiki user would need to save the rendered page
as html file locally, until he/she could use file:// links pointing to another
local stored file.

I changed the bug status to RESOLVED / WONTFIX, as the non-working of such
file:// links cannot be influenced by changes of the wiki software, as it
depends only on the client's browser.

phlipping wrote:

Does anyone know, why three slashes are needed ? Isn't that another (small) bug ?

The definition of a URL with a path is protocol://host/path (plus some other
stuff, but that's the simple form)
Technically file urls should be file://localhost/path but this is usually
abbreviated as file:///path (ie no host) since localhost is the only computer
you'd want to use file: for anyway.
Most browsers will accept file://localhost/path (tested in IE and Mozilla,
Mozilla also accepts file://anyhostname/path and treats it as localhost but IE
will only accept "localhost" - not even "127.0.0.1" will work)