If I want to insert an inline image in a new mail I am able to select the jpg file in a folder like this
C:\Users\master\Downloads# 1 SD #\test.jpg
The JPG will be shown and everything seems to be fine.
But when I hit “SEND” I get an error message that says that the file “C:\Users\master\Downloads” couldn’t be attached because an error has occured: A part of the path “C:\Users\master\Downloads” couldn’t be found.
As you can see the path is missing the last subfolder “# sd #” and also the filename in the first part of that message.
Therefore I assumed that the cause might be the '#" characters in the pathname.
I moved the file one level up and then everything works fine.
I don’t think that it depends on the Release 6.0.21040
I don’t have the chance to rename the folder because these are my folders from a network where a whole team has to work with.
I don’t like to move each file a few folders up or to copy each file to the desktop before attaching.
It works for a week or 2 but not in the long run.
Thx
WOLF
Hi Wolf, can you please update your eM Client to this release, http://www.emclient.com/dist/v6.0.21372/setup.msi and check if the issue persists? If it does, can you please make a screenshot of the error you’re seeing and specify how exactly you’ve been attaching the inline image?
Have you been using the drag and drop feature or did you insert it using the insert option in eM Client?
Thank you,
Paul
Hey Paul,
that issue is still there under the new version.
As described I was able to select the folder and file - so I did not do it with drag & drop.
I have used the insert icon above the body field of the eMail, then I selected the file in that particular folder # SD#. After that the image is embedded, everything seems to be fine.
But if hit the send button I still get the same error box you see here:
As you can see the complete folder ‘# SD #’ is missing or even the complete part below the folder with the first ‘#’ (hashtag) . If I chose ‘\Downloads# SD #\Hans\2013\test.jpg’ I got the same message above with the SAME INCOMPLETE folderpath. - every folder below the first ‘#’ is cut off from the path in that error message box
We use the ‘#’ intensively for sorting purpose and to get a SPECIAL ATTENTION for these folders which are on top of the list. This works quite good especially for SHORT FOLDERNAMES.
Hope that helps
Thx
Andreas
hi again Andreas, does this occur with image attachments to each message, or is it possible you have a network location setup for an image in your signature, if you have one?
I’m afraid this might be caused by the network location rather than by the name of the folder.
Regards,
Paul
Please ignore me if I’m butting in. I’m not sure about the “network” part of this. The example shown above shows the C: drive. So, Andreas, are you using DFS to map network shares or do you copy the network directory structure to your local disk or is it something different?
Paul - can you ask the developers if they do anything when parsing filenames which ignores something if they find a # character?
Alan
Hey Alan,
#1 - the problem occurs in all situation on the network and locally on drive C:
#2 - I only mentioned the network due to the fact, that this “#” FOLDER naming convention is part of our collabrative environment and I am not able to change the “#” easily by something else because the # is in all documentations explained as a marker for special/high priority
As I mentioned above your eyes will recognize these folders as “something special” without any explanation if you use it at beginning and end of a folder name like “# SD CARD #”
#3 - all of my many tests above were based on local drive C: and I tried to isolate the cause of the problem in different scenarios before I started to write here.
Believe me it must be that ‘#’ thing because if I replace the ‘#’ by a character like ‘p’ everything works fine.
Andreas
Ok - so back to paul to check with his developers. There must be something in the code.
Cheers
Alan
Hey Paul,
I do not use any signature.
All my further tests and investigation were based on local drive C.
And the only special thing is that ‘#’ in the foldername.
I had different approaches because first I thought it would have been something different like a character in the filename. Therefore I tried it with a simple filename ‘a.jpg’ that either did not work.
So it must have been something different cause I knew that this inline image thing had worked the weeks before. It took quite a few time until I figured out that I only used the desktop or the downloads folder in the weeks before .
I tried to embedd the “a.jpg” file from the downloads folder - it worked.
Then I moved the a.jpg file to ‘\downloads# SD #’ and it did not work
If you read the message above carefully you must have noticed, that even inside the error message the complete foldername part after “#” is missing in that box.
Just make these simple trials with a “downloads# SD #” Folder and an “a.jpg” file . The embedding does not work. But you will get the error message only if you press the SEND button, the error box does not occur earlier.
You are not able to send this message.
If you want to send it than you have to do these steps
#1 delete that inline image
#2 move the file with the explorer from the # sd # Folder a few levels up to “desktop” or “downloads” Folder
#3 to embedd the file from the new folder in the message again by selcting the file from “downloads” folder
Then the eMail will be send without any complains or errors.
The error might sound strange but it 100% reproduceable.
Andreas
Or, it could be an underlying Windows issue if they are making Windows calls to parse filenames.
I MADE A MISTAKE ABOVE
I WROTE:
"Just make these simple trials with a “downloads# SD #” Folder and an “a.jpg” file . The embedding does not work. But you will get the error message only if you press the SEND button, the error box does not occur earlier. "
THERE IS A MISTAKE HERE: “The embedding does NOT work”
This is somehow wrong because the pure embedding itself works fine until you will try to send the email. Then the trouble begins cause you are not able to send.
So EMBEDDING itself is OK, but in the follow up the problems occure.
Andreas
Hi again Wolf, I’m sorry for the belated reply, I’ve discussed the issue with the developers, however it seems highly likely that the issue is really caused by the # sign in the URL. Thank you for reporting this issue, we’ll be working on a fix for future releases of eM Client.
Thank you,
Paul
Hey Paul,
as I told you - this is a nice bug because the developers won’t /can’t believe it how something like that could happen - but it happened and it might be there are other special character’s that won’t work.
So let me know if you have fixed it because then I will download a new version.
I do not change very often because I have got only a mobile data plan and therefore I don’t jump on any new release …
Thx.
Andreas
Hi again Wolf, I’ve informed the developers and just got a response that a fix should be included in a future (next) update. Thank you for reporting the issue, please make sure to let us know if you come across any other issues or questions about the application, we’ll be happy to help.
Thank you,
Paul