When sending an email containing a local link (i.e. file:///X:/scripts/out/find-missing-url.result.txt), I have to ensure, by editing the source, that it is not an anchor <A> and it is only under a <DIV> element. Sending like this, the link is clickable.
P.S. By the way, it seems that HTML injection is possible using the forum. I realized this because at first I wrote the “<” literally and it was treated as HTML. So changed it to be an HTML encoded version.
Local file links won’t be clickable, because the recipient won’t have access to your local files.
Have you considered using eM Client’s cloud attachment feature?
Find out more about that here.
The issue is not if the file exists on the local machine or not, because the email sent was an internal one and thus the file exists.
The issue is that the link is not clickable without editing HTML before sending the email.
Summary: The URL is not a transpose as a link <A href=“file:///MYPATH”>. It is shown as text only and thus not clickable.
martes 15 febrero 2022 :: 0908hrs (UTC +01:00)
I do not know how you are creating your link, if you are using the Insert Link shortcut…
the link will be shown as whatever you have entered, not HTML code.
It will work, assuming everything is entered correctly and the code is pointing to a
file on the local computer - not remote unless that is where the file is (see @Gary above)
You need to Hold Down the Ctrl key when you click the Link (text or whatever)
¡Saludos desde la soleada Sevilla España!
Skybat
emc_forum@compucall.com
Hablo español, luego portugués e inglés, con conocimiento de varios otros idiomas.
There is no way that the application can know that the message is internal, nor is there a way the application can know that the recipient has scripts also mapped to X:. So the link is not clickable because it refers to a local file on your device.
And what is the expectation when the message is received by a user with a Mac, even if he is sitting next to you in the office? That link is never going to work for him, even if you alter it as you suggest.
See my next answer to Gary.
I will try to clarify the situation, but first of all, I would like to say that I am a senior software engineer and I know the issue is located within the software. Why I know this? Because there are two behaviors depending on how I send it.
Methods used to send:
Hoping I was really clear. I don’t want any EmClient user support for this issue. I would like the bug to be reported to the development team.
This is not a bug, but an intended behavior.
The reason is that there’s simply no valid use case for URLs such as file:///x:/path/to/the%20file.txt since each recipient may have the drive letter mapped differently even when used inside the same organization.
We do allow file URLs pointing to shared disks that use the UNC format of the URL, eg. file://hostname/path/to/the%20file.txt.
Agree with @Gary this is not a bug. Mailers are “not normally” meant to share LAN URL’s that way.
However on sharing a Local LAN directory or Local LAN files links if using a eg: Windows PC via eM Client or “any other mailer” is that when i insert a “Link” i do it this way “which works” for me -
When you do then open the LAN link in the email, you will get the Open Dangerous “security warning” dialogue box in eM Client as per below example, but that’s normal being its a LAN local folder or file.
(LAN Directory) 
or (LAN File) 
I’m following up on this older discussion. I agree with Master_DJon. Gary I think you are wrong with your argument. For our customers, users within the internal LAN use the same letter for the network drive of the main data structure. As part of the information sent, the Secretariat sends links to folders within the data structure where the necessary documents are stored. With Outlook, users are used to clicking on a link and opening a folder from a network drive. It’s not possible with emclient, or at least not easily…how to explain to the assistant to replace the drive letter in the link with a UNC path that she doesn’t even know?
They purchased Emclient and are having a problem with it because of this functionality.
At least as an option to turn on this functionality.
As I said, we do allow file URLs pointing to shared disks that use the UNC format of the URL, eg. file://hostname/path/to/the%20file.txt .
Please try that if possible as we don’t support the other option because the drive letter may not be constant across devices.
There are a lot of email that are sent within the same network which computers have the same configuration. So, at least just say, “we don’t want to implement this” instead of a pale argument like this. The intended usage and novel usage may not be the same, but as software developers, we shall always consider both.
That’s my final word on this.