What

I'd love to see disk paths rendered into clickable hyperlinks just like http:/... links do. Maybe it's an extension of the idea of AbsoluteWikization, but I'm not so much into the details.

Please see SlashFilenamePlugin

TWiki page attachments are good if they are static, but they are cumbersome to update or even get to without using TWiki. This would be extremely useful when using TWiki as an intranet that makes references to file and folder locations without having to attach them. If we can have disk path references, then we have a very powerful symbiosis between a file server as a data storage and an intranet as a knowledge storage.

At any rate, my suggestion is that anything written as e.g. C:\My Documents gets turned into a hyperlink with HREF=''C:\My Documents'', and C:\This File.doc gets turned into a hyperlink with HREF=''C:\This File.doc''.

How

I think using a pattern of equalsign-diskpath-equalsign has two advantages:

• It is rendered as monospaced, which makes it easy to recognize, and
• It is simple to write and the equal signs nicely handles the problems of names with spaces.

I know, I know. There are downsides to this idea too:

• Very long disk paths can't be hidden in square brackets
• Doesn't port at all between file systems (unix, pc, Mac, etc.) but this is okay in my view because that will be evident from context anyway.

Does something like this already exist? I haven't been able to find it but if it does, please add a link to it here.

-- TorbenGB - 22 Apr 2002

This would be quite useful where I work, since there is a large shared disk area used for project documents. We would have to pick a different syntax from your proposed =c:\path\to\file=, though, as that's already used for rendering text in fixed-width fonts.

I suggest extending the existing linking syntax somehow, e.g. [[c:\path\to\file]] - we could also use [[c:\path\to\file descriptive text]] for filenames without spaces, and [[c:\path\to\some file][descriptive text]] for filenames with spaces.

These links should also support the file:// syntax as that is the standard way to link to files.

This is best considered as a migration tool - it's very easy to generate these links, but you end up with TWiki as a thin layer over a file system.

-- RichardDonkin - 22 Apr 2002

I think this is too specialized to take into the core code. Also, it can be missleading, users could start publishing their files on the C: drive and wonder why other folks can't see it.

A simple way to allow file URLs is by adding a file rule to the InterwikiPlugin, e.g. you could write File:c:\path\to\file

-- PeterThoeny - 23 Apr 2002

This should probably be done as a plugin, as Peter says - mainly because publishing documents as file:// URLs is something of a backward step, and people should be encouraged to just attach them to TWiki pages or convert them into TWiki syntax.

Any such plugin should have a configurable %SHARED_DIRECTORY_PATTERN%, or a list of drive letters, that matches the allowable shared drive paths, thus preventing people from putting in file:// URLs that don't point to a shared path. Of course, on a laptop TWiki that is not network accessible, files on the local hard disk would be OK. Even with this feature, it's possible to put in links that not everyone can follow, due to Windows file permissions, so it is generally better just to attach the files to TWiki.

The Interwiki idea will work for filenames without spaces, otherwise they'll need encoding as %20 for space, etc.

-- RichardDonkin - 23 Apr 2002

ClipName - http://www.mainsoft.fr/en/freeware.htm - is very useful for getting the name of a file/dir path onto the clipboard. The author modified it after I suggested that it should be able to paste a URL encoded version.

-- MartinCleaver - 23 Apr 2002

How about attaching a Microsoft Shortcut (link icon) to a wiki topic/page?

or

HTML for the link? C:/Program Files/

-- SocinianClarke - 23 Apr 2002

Attaching a shortcut seems rather heavyweight. HTML is of course possible, but I think the idea is to define a syntax that's easier to use.

-- RichardDonkin - 24 Apr 2002

No MS shortcuts... this would be the ultimate in non-portability. A file:... link will do just fine. In particular, the browser will take care of all platform-specific things like forward/backward slashes, drive letters, and such.

Implementing HTML would be trivial, just add file: to the list of recognized protocols (together with http: and https:). Oh, and while we're at it, please also add mailto: - if a mailto address doesn't have a @ (e.g. because you want to leave the mail address out and just provide subject and body), you'll have to use the full HTML syntax.

I don't think that people will create lots of local links. Just make sure that uploading is easier than adding a local link, and people will make the Right Decision automatically, without even thinking about it :-).

I'm a bit uneasy about security issues, but since it's just the browser that locally loads the file and the server doesn't even see it, I don't think that any real issues are lurking here.

-- JoachimDurchholz - 25 Apr 2002

The file: syntax is already supported in TWiki (at least in alpha), at work I find it useful to refer to large shared drives, but for individual documents I'll always upload to TWiki. mailto: should be the subject of another topic.

-- JohnTalintyre - 25 Apr 2002

mailto: is not just the subject of another topic, it's been coded... Mailto is greatly enhanced in TWikiAlphaRelease - see EmailThisPageLink. This supports mailto's without '@' in the link, e.g. [[mailto:?subject=Hi Email to say hi]] creates Email to say hi.

Please follow up on EmailThisPageLink.

-- RichardDonkin - 25 Apr 2002

Thank you all for a good discussion on this suggestion. I was not aware that I could use the file:// prefix to make it work just like I want it to.

You also gave good arguments for using other methods, which may be of more use in other situations.

IMHO, attaching the files directly to the web pages make the updating of the files a little too cumbersome - files should be as easily accessible as the web pages themselves. After all, sometimes a web page simply isn't the best medium. E.g. there are spreadsheets or flowcharts which are not easily ported to TWiki. But only if they are pretty static is it useful to attach the files themselves to the web pages.

Of course, a shortcut to the file on disk might be a workaround, but you still have to get it before you can follow the shortcut, and the shortcut target is not visible until you follow it.

In my work situation, it's a great benefit to be able to reference disk files right in the middle of the topic, which is where the file:// prefix is simply perfect. As to the risk of it making TWiki just a thin layer on top of a disk structure, I'm not worried. For most knowledge content, maintaining it is still easiest and most convenient on TWiki.

I don't see it as a backward step, necessarily. Yes, if it ends up with just one index.htm page to the entire disk structure, then it became backwards, but consider the other end of that spectrum -- how you would you migrate large spreadsheets, flowcharts, presentations, databases, etc. in TWiki's syntax?

-- TorbenGB - 02 May 2002

I think the attachment model and file:// model both have advantages - we are aiming to use TWiki attachments to store essentially all process deliverables in our new Quality-driven intranet structure (you click down through a process, through a non-TWiki website, and get to a TWiki page that is nothing but attachments). TWiki's ability to version attachments is quite important here.

I'd be interested in discussion on DocumentManagement, for people who have done a similar structured doc management system (I hear that one TWiki site replaced Documentum...)

As for file:// links, here are some links to file:///c:/boot.ini - Link to Boot.ini (using TWikiAlphaRelease's EasierExternalLinking format, i.e. [[file:///c:/boot.ini descriptive text]]), and Another Link to Boot.ini (using conventional link syntax, i.e. [[file://c:/boot.ini][descriptive text]]). You can also link to Program Files using the conventional syntax, without having to write %20 for spaces.

These links work OK in IE5.5, Opera 6.01 and Mozilla 1.O RC1, all on Windows (Mozilla needs file:///, i.e. three slashes, and seems to have a bug whereby it can't follow the links although they work when typed in) - however, I'm not sure whether some characters should be escaped for other browsers.

If people want to do a lot of file:// links easily, it would be useful to do JavascriptBasedEditor features to let you browse for a file when creating a link (if that's possible in JavaScript, may not be for security reasons).

Some sort of easier linking format would help, e.g. to transform [[c:\path to\foo.doc][descriptive text]] into [[file://c:/path%20to/foo.doc][descriptive text]]. This could be prototyped as a plugin, but in the longer term would IMO be useful in the core code given the TWikiMission focusing on intranets, which are dominated by Windows desktops. Of course, any solution should also work for MacOS and Linux/Unix desktops as well, and we should encourage people to use attachments rather than file:// URLs, but in some cases the files exist outside the TWiki domain.

One very useful feature for such a plugin would be latest-version matching, i.e. the ability to find the latest instance of a given file name, where part of the name is a version number or date. This should definitely be done in a plugin, and might require a background task, but would be useful for other URL types as well, e.g. HTTP URLs, not just file:// URLs. This would make it much easier for me to link to a particular spreadsheet from TWiki.

-- RichardDonkin - 02 May 2002

What we did at work was to define a variable that points to a project specific directory on a shared drive, e.g. Set XYZDOCROOT = file:///S:/Xyz. That way you can define links like %XYZDOCROOT%/subdir/file.ext or [[%XYZDOCROOT%/subdir/file.ext][file]].

This discourages the use of links to local disks and encourages everyone to use a shared drive.

-- PeterThoeny - 02 May 2002

Just for the record: the InterwikiPlugin serves this purpose as well: add a rule like

Then you'll get something like ProjectDrive:2003/plan/foobar.doc

-- PeterKlausner - 11 Apr 2003

Hey the interwiki thing works well. My only complaint is the the alias has to be at least two letters. If a single letter was allowed, then paths could be cut'n'paste straight across. For example Z:\documents\2003\SummerProjects.doc. This would work well on our intranet where there are certain drive letters which are guaranteed to be mapped the same for all users.

Mozilla does not follow file:// links on purpose because security concerns. Many users disagree, but so far the coder in charge of this area has held firm. You can bypass the security feature by editing the preferences file. Gory details at MozillaBug:84128

UPDATE: actually I have another complaint too: backslashes don't work, only foreslashes.

-- MattWilkie - 12 Jun 2003