MsgViewer icon indicating copy to clipboard operation
MsgViewer copied to clipboard

msg2eml: files with similar but longer names result in being duplicated

Open datsteves opened this issue 3 years ago • 4 comments

When converting a msg with an inline image and an attachment with similar names, they result in being duplicated.

In this example, there are two images.

  1. 2017-10-01 11.23.09.jpg - a simple attachment
  2. 2017-10-03 11.11.25.jpg - used inline.

as they do have similar names and get shortened to the same filename, they then are the same base64.

you will find two times this part in it.

------=_Part_0_926434463.1661862883281
Content-Type: image/jpeg; name=2017-10-.jpg
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=2017-10-.jpg

/9j/4aqnRXhpZgAATU0AKgAAAAgADwEAAAMAAAABD4AAAAEBAAMAAAABC6AAAAECAAMAAAADAAAA
... more base64

don't know if that would happen if it would be two simple attachments, but could be the case too.

I attached a version of what it actually should look like. at least when it comes to the attachments

for me personally, it would be just good if the base64 wouldn't be the same as I actually just use that. but if the file names are not the same too, would be even better :)

Files

Mail with attachment.zip how it should look like - inline-image.eml.zip

Side note

btw. would be nice to have, if the attachments can get the Content-ID too :) would at least make it a lot easier to work with those files when they are inline.

datsteves avatar Aug 30 '22 13:08 datsteves

Both attachments have the same filename in the original message. However they have different long filenames. Unfortunately it's the short filename that is used to temporarily store the image. I'll fix this. I'll also fix the content-ID. I just need to do that in a clean fashion suitable also for attachments without content-ID

lolo101 avatar Aug 31 '22 15:08 lolo101

There is another issue that looks like a regression: the embedded image does not show up in the original msg

Edit: maybe not a regression after all. I could reproduce the bug with older releases up to 1.4.0

lolo101 avatar Sep 01 '22 10:09 lolo101

Created another issue for the embedded image: https://github.com/lolo101/MsgViewer/issues/128

lolo101 avatar Sep 01 '22 20:09 lolo101

Several changes have to be done

  • in MBoxWriterViaJavaMail these lines are problematic
                part.setFileName(MimeUtility.encodeText(fatt.toString(), "UTF-8", null));
                part.attachFile(dumpAttachment(fatt).toFile());

because part.attachFile invokes part.setFileName once again but with the filename returned by dumpAttachment(fatt).toFile()

  • dumpAttachment(FileAttachment) behaves differently from ViewerHelper.getTempFile(FileAttachment) the first one returns the short filename whereas the second one returns the long filename whenever possible.
  • ViewerHelper looks like it is creating its own tmp directory and exposes a dispose() method to clean it up, whereas TempDir.getTempDir() already returns an auto-cleaned tmp directory

lolo101 avatar Sep 02 '22 00:09 lolo101

@datsteves let me know if the last commit fixed all issues for you so I can make a new release

lolo101 avatar Sep 04 '22 18:09 lolo101

@lolo101 yep, both scenarios are working as expected now. Thank you very much :)

datsteves avatar Sep 07 '22 12:09 datsteves