Sounds like a good idea, but I think it would be difficult to implement on all the different platforms.

I tried this out by just adding a file:// link in a note. Neither Firefox nor IE would actually open the link (WinXP). Yet I have bookmarks that use file:// links (for local documentation and whatnot) that work fine. Maybe there is some sort of security feature in both browsers that disallows file:// links from real webpages to work.

An alternitve maybe a file upload / storage system in Tracks?

hmm, I just can speak for the Win side: to link (and call/display/open) files and directories works fine for me with IE (5.5 and 6), Firefox and Opera on W2k (which shouldn't be different from XP regarding this matter). You could simply call directories without the "file:" part, [c:\ simply like this] (try it) either IE or Firefox.

I covered Firefox more in detail in #141.

If this doesn't work for you I would recommend doublechecking your personal security settings or third party software issues (firewall etc.) because I really cant imagine this method not to work. Especially because it aren't real webpages in this case and the call normally shouldn't care a web server (webrick, apache ...).
Internet Explorer even falls into "(File) Explorer" mode when listing local directories.
Opening files should AFAIK be set by either folder- and/or extension settings of windows in this case and has nothing do do with the browser in general.

Let me know if you're still having trouble with that.

Yeah, your link didn't work for me. In Firefox, I get "c is not a registered protocol". In IE 6, nothing happens. Maybe my security settings are too strict (or, perhaps yours are too loose). Oh well...I'm not the one interested in the feature anyway. :)

> In Firefox, I get "c is not a registered protocol"

after playing around a bit with that, it shows, that I get the same message if calling some of the following from within Firefox:

c:/
c://
}}}

but those

{{{
c:
c:\
file://c:/
file:/c:/
file:c:/
(and last 4 with a backslash "\" at the end instead of forward "/")
}}}

are automatically translated into 

{{{
file:///c:/
}}}

which shows the directory.

IE 6 works with

{{{
c:
c:/
c:\
file:///c:/
file://c:/
file:/c:/
file:c:/
(and last 4 with a backslash "\" at the end instead of forward "/"
}}}

but not with

{{{
c://

(file not found)

> Maybe my security settings are too strict

although mentioned before I don't really believe that. From my experience you would receive some error message which points out security issues...

Thought I'd post this as an FYI...

It seems this is a "feature" of Firefox afterall. There have been some bug reports filed about it. The main one appears to be "Bug 84128":https://bugzilla.mozilla.org/show_bug.cgi?id=84128, which is over 4 years old and still open. They can't seem to decide what to do about it. Interestingly, there is an error message generated for this behavior, but it only appears in the !JavaScript Console. Kind of a silly place to put it, IMO. And there is a configuration parameter (security.checkloaduri) that enables or disables this behavior. So there you go.

LOL that's good.
But I don't know if this could be really considered a bug...? But I don't know if I get you right either...?: what exactly is a bug in Firefox? That you can open local files? Hmmm, I would consider some of IE's behaviours as a bug also, then - for example if you call a local text file from within IE and it opens that file with the professional and useful notepad.exe system utility - LOL (same might happen with registered image formats...)
If I open a file with a web browser - I want to see that file in the browser - not in any other application - but that might differ from other people's needs of course...
(wondering if that bug already had been mentioned to Microsoft? ROFL)

Updating tickets (#373, #105, #107, #117, #125, #126, #147, #177, #182, #183, #185, #197, #202, #206, #220, #236, #240, #276, #283, #294, #300, #305, #309, #312, #317, #324, #337, #357, #358, #360, #433, #452, #462, #17, #74, #82, #92, #123, #265, #431, #440, #475, #94, #256, #258, #464)

Migrated to GitHub issue #1541