Linking to a Shared Folder (Windows Explorer, UNC) from WebHelp

[Nadja211]

Hello Folks,

I have been wondering about this now quite some time, and maybe it is simple, and I am just being too blind to see a solution:
I would like to have clickable links in my WebHelp (HTML output - NOT chm) that direct to an internal file share UNC on the (same) network.
So that the Windows Explorer opens on click-on-link at the specified share folder - Like "click here"...-> "\\server\sharename\folder\".
Is this possible at all?

I cannot have the link point to the executable file to download directly, as this one is just a related tool and gets updated more often than the Online Help does - and it always has its recent version in the file name, so I cannot link to a 'permanent' (static) file name.
Besides, there is some interesting additional information in this file share, so I'd like people to see 'all about this tool', and therefore open the shared folder which contains it all, when they click the file-share link in my Webhelp.

I have tried many things and config-options in the Link options, yet to no avail. I cannot get a "\\server\share\folder" UNC-type link, when published to a WebHelp, to be treated as it should: open the local Windows Explorer at just the specified point.
(Specifiying the 'explorer.exe' to be used (in the link options), with or without full path, did not help.)

Please tell me, what am I missing here? Is it possible at all?

Thank you very much!

Best regards

Nadja

[Simon_Dismore]

I would like to have clickable links in my WebHelp (HTML output - NOT chm) that direct to an internal file share UNC on the (same) network.
So that the Windows Explorer opens on click-on-link at the specified share folder - Like "click here"...-> "\\server\sharename\folder\".
Is this possible at all?

Have you tried file://///server/sharename/foldername?

[Tim Green]

Hi Nadja,

In addition to what Simon wrote, the file: protocol should have two slashes when accessing something on a UNC path with specification of the server name, like this:

Code: Select all

file://server/sharename/foldername

When you use three slashes it is shorthand for accessing a file on the current machine -- then "localhost" is assumed instead of the server name.

File URIs can have two or three slashes; both are syntactically correct but semantically different. Three slashes (equivalent to omitting “localhost” between the second and third slash) is used to access local files. Two slashes (as long as the host is not “localhost”) is used to access files in a remote system.

[Simon_Dismore]

Code: Select all

file://server/sharename/foldername

AFAICS two slashes are supported in some browsers but not in Firefox, whereas five slashes are supported everywhere. It's mentioned in RFC8089.

[Tim Green]

AFAICS two slashes are supported in some browsers but not in Firefox, whereas five slashes are supported everywhere. It's mentioned in RFC8089.

Yes, as usual the browser vendors have turned a clear specification into a dog's dinner. In the appendix, the RFC8089 you reference actually states this, indirectly:

Code: Select all

According to the definition in [RFC1738], a file URL always started
   with the token "file://", followed by an (optionally blank) host name
   and a "/".  The syntax given in Section 2 makes the entire authority
   component, including the double slashes "//", optional.

Appendix B.  Example URIs

   The syntax in Section 2 is intended to support file URIs that take
   the following forms:

   Local files:

   o  A traditional file URI for a local file with an empty authority.
      This is the most common format in use today.  For example:

      *  "file:///path/to/file"

   o  The minimal representation of a local file with no authority field
      and an absolute path that begins with a slash "/".  For example:

      *  "file:/path/to/file"

   Non-local files:

   o  A non-local file with an explicit authority.  For example:

      *  "file://host.example.com/path/to/file"

That is the way it should be handled. The best comment on this is still from XKD (even though it's not 100% this, it's still exactly the same psychology at work):

standards.png

[Simon_Dismore]

That is the way it should be handled .

Perhaps we're looking at this from different persectives? I was just suggesting something that might work, which apparently is legitimate in the current RFC

If you're frustrated by the evolution of web standards, join the club (I served on an ISO TC97 working group in my youth), but complaining about that doesn't really contribute to H+M forums, does it? If Firefox wants five slashes, OK so be it, could be something useful to share. AFAICS similar compromises have been fitted into [holds his nose] JQuery, but that doesn't stop people from using it.

[Tim Green]

Hi Simon,

Perhaps we're looking at this from different persectives? I was just suggesting something that might work, which apparently is legitimate in the current RFC

You're right there, of course. I had actually always thought that the two-slash/three-slash model was a standard that really did work everywhere, including in Firefox. I had never even seen the five-slash model anywhere until you posted it, and I originally thought it was either a joke or a typo, or possibly the forum software doubling up escaped characters. (It reminds me of an old Onion article, in which they described, as a parody, razors with five blades, which then proceeded to became a reality.) A quick Google search on the subject reveals that the five-slash issue is a contentious Mozilla snafu going back at least twenty years, and it seems that they have still not managed to resolve it conclusively.

I served on an ISO TC97 working group in my youth

Interesting -- I had always pegged you as being someone in their early twenties...

[Tim Frost]

Horror! Do I have to stop and think with every posting 'do I look too old in this?'

[Tim Green]

Horror! Do I have to stop and think with every posting 'do I look too old in this?'

I really don't think so...

[Nadja211]

Hello Simon, Hello Tim,
many thanks for going into all these details! I have just learned a lot!
Sorry that I could not check back earlier, had a lot of urgent but non-related stuff to do.

I have now tried the "Five-Slash solution" on a small demo project, and this seems to work - at least with the H&M own test-webserver (127.0.0.1 ...).
Could not yet test it on the real thing, as this baby of a documentation takes nearly one full hour to publish, but will try it all out when next real regular publish is due (soon).

Funny, I have tried it before with two and three and four slashes, but five... - this I must have missed! It looks promising.

Firefox is not really critical, would be just a nice-to-have, but mainly this needs to work with Chrome and (you are now eligible for 3 minutes of a hearty laugh), the last IE version (not Edge).

The regular syntax as proposed by Tim (file://server/sharename/foldername) has never worked on the live project yet (this, in fact, is how it is at the moment, in the published version it just gives an error 'not found'. - Maybe this has something to do with the target folder being located on a DFS share - I have no idea yet. Or with the old IE. Or...? -> yep, there's my problem again ^^)

(Another 'funny' thing is, when inserting a link using the <Ctrl+L> dialog, the "Test" function will always work OK - for any amount of slashes! - but from the H&M Editor the link then is always "Not found". When published, it then did not work, either.)

I will try both primary suggestions on the REAL webserver as soon as possible and then get back to you.

Thank you very-very much for your efforts and all the information!

Best regards

Nadja

[Nadja211]

OK, have now tried everything on the real webserver in the real customer's environment.
To whom it may be of interest:

------------
Test setup:
Used a small demo project and inserted links to the shared folder in different ways.
Actual UNC path is like this: \\subdomain.domain.net\DFSsharename\MainFolder\SubFolder\Targetfolder .
(the first part not being an actual server's name is due to this being a DFS share, which always uses the (sub-)domain FQDN.)

So I put this target in links with various amounts of initial slashes:
Link1 = file://subdomain.domain.net/DFSsharename/MainFolder/SubFolder/Targetfolder
Link2 = file://subdomain.domain.net/DFSsharename/MainFolder/SubFolder/Targetfolder/ (=with a tracing slash - just in case ...)
Link3 ... (with /// ... and so on); up to
Link8 = file://///subdomain.domain.net/DFSsharename/MainFolder/SubFolder/Targetfolder/ .

Then published it (using the same skin as with the 'large' project), and tried with three different browsers.
------------
Outcome in short:
- No luck at all with Chrome and Firefox. But does work with IE11 (very amazingly) now.
- The target "file://...." link, however, does work with every browser when pasted directly into address bar (Except FF, which adds one more / - but there it's ok with 4 or 5 slashes). Thus, it also works when using "Copy Link Location" and pasting it in address bar of new tab.
(It just seems not possible to get this by using the link itself, in Chrome + FF).
- Difference: IE11 opens the real Windows (file) Explorer. Chrome and FF, when entered a direct "file://..." link, open the folder contents in a web page view.

Outcome in details:
1. Google Chrome browser:
Does just nothing - on every single version of the link.
Right-clicking on the links and "Open in new tab" shows "about:config#blocked" in the address bar of the new (blank) tab. No errors.
No idea which setting in Chrome causes this. My Chrome has nearly unchanged customer standard settings, just as distributed by their software management. I did enable "Allow Pop-Ups..." and: "Allow unsafe content...". - No difference.
Interesting: The links that use four, and five, slashes are treated by Chrome as having only two //. (As shown on mouseover). "Three" remains unchanged. (But still, nothing works)

2. Firefox:
Does just nothing - on every single version of the link.
Replaces the // - Links with /// (three). The 4 and 5-slash links it does not change. Opening either of them in a new tab shows the "file:///(/...) ..." link in the address bar, trying to load it, and failing. No errors.

3. Internet Explorer (IE11)
This is what now stumps me most:
IE works on ALL link variants except the 3-slashes-thing (which was not meant seriously anyway, just included this to see what Firefox would do.)
IE does not replace anything by itself, uses the given amount of slashes and opens the target folder with 2,4 and 5 slashes.

BUT...

... the IE was the default browser with which my Webhelp had to work, until a few months ago. Only now it's being phased out / discouraged.
-> So all testing I have done before, which made me ask this topic here in the first place, was done mainly for IE! - where nothing worked, when I last tried (yes, with the correct 2-slash syntax). This was around February.
In my webhelp, I could not make it work and gave up then, removed the link function altogether, and just told the users, as a workaround, to copy-and-paste the file://... share link to their windows explorer.

It was always up to the users which browser they preferred on their machines, but when the help is opened directly from the program on the Terminal Server, then it was IE or nothing. Just recently this default was changed to Chrome. -> This fact now sent me to trying once again, but this time with Chrome only - and then asking for help here.

My only explanation is that something I am not aware of, concerning the IE (settings?), must have changed on the customer side since February.
But whatever it was, sadly now does not matter, as now it has to work with Chrome... which it does not.
Very bad timing. Just my luck ^^ )
---

I think I'll stick with the workaround to have users copy-and-paste the link.

Except if any of you now have a spontaneous glorious insight. Much appreciated, of course!
But, please, do not put too much effort in there.
The 'elegant' solution, if there is any, is probably not worth the trouble...
And, of course I cannot demand the company should change their administrative browser safety settings (if those are the problem. Still not sure yet).

Thank you very much!

Best regards
Nadja

[Tim Green]

Hi Nadja,

This may have something to do with (possibly recently updated) security settings for browsers accessing external files on Windows from within the web server's filespace/namespace. That would explain why it works in IE and not in other browsers, because IE would be the only browser that is still actually part of Windows. You can easily test this by opening the WebHelp directly from the disk by double-clicking on the index.html file. You will find that your file links then work fine, because the WebHelp is then not inside the web server and being blocked from reaching outside it.

I'm going to check with our developers on this (this is an area I'm not sure about). However, generally speaking the best way to access external files from any web page is to put them on the web server as well, so that you can link to them with a normal relative URL. As attacks on all sides become more intense, browsers and servers are being locked down more and more effectively.

[Nadja211]

Hi Tim,

once more, thanks a BIG lot for your help.
Yep - can't explain this to myself other than with some obscure updates that occurred while I had already given this up.

As for easily testing:
For some reason, double-clicking the index.html on the web server opens just a nearly-blank page to me (in Chrome). It has the skin design with the frames, the banner picture, and the custom link menus to the upper right, and the tabs ("Topic text. Keyword Index, Search") but no contents in the 'tree' frame nor in the main frame. Double-clicking on any html topic file directly will briefly show contents, then redirect to the 'index.html' with no contents.

When trying this in a local output folder on my computer, with no web server attached (just starting the index.html file), Chrome says No.
Gives some lenghty information that it was blocked because of cross-site scripting, and please use a different browser...

... so, sorry: cannot verify!

I am very glad you are reading my postings. Thank you very much, and have a very nice weekend!

Bye,

Nadja

[Tim Green]

Hi Nadja,

I'm pretty sure this is a permissions issue and that in the long run you will really have to put the files you want to link to in one of the web server folders and link to them there.

One important question: Are you creating the links in Help+Manual with the File link or the Internet link option? If you create with File link option you won't be able to store the file:// prefix, it will automatically get converted to a regular UNC path.

[Nadja211]

Hello Tim,

Thanks for the reply. I use the "Internet Link" option.
(Sorry, could not test anything in the past week, working on something else, not involving H&M.)
You are most likely right about it being a permissions thing.
Now I still have to find out whether having the folder directly on the webserver would make a difference.
If it works, then I'd best try to convince the server admin to implement a script task that copies the target folder to the web server whenever something changes.

Best regards

Nadja