** Observed with 6/14/99 Mac build ** The above URL contains I18n smoketest file containing 5 msgs, Latin 1, Japanese and UTF8 messages. This was created by a Windows client. Mac messenger 5.0 has a problem with Windows line breaks apparently and I am not able to display Message pane header and body correctly -- for the header, I see nothing for most of the messages and for the body I see RFC 822 text type display. The view pane display does work.

When I converted the smoketest file into Mac type line breaks, all the Message headers and body text showed correctly.

Corrected the paltform & OS to Mac.

I want to add that one of the 5 smoketest msgs is mail with an attachment. I was never able to load this message when I selected it -- it kept on trying to load over and over again and it actually froze the apprunner. There seems to be some sort of infinite attempt at loading this particular message. When I changed the line breaks type to the Mac one, I did not have this problem.

The message parser is supposed to be smart enough to accept any linebreak style. If we've broken that, we should fix it. Reassigning to bienvenu.

No, this didn't work in 4.x either, I'm afraid. But there weren't any infinite loops, AFAIK.

This was working before (I used the smoke test data to test my fix cross platform on 6/9). I don't see the infinite loop but it takes long time to process a message in the smoke test which has an attachment.

I haven't changed the message parser in months. Is this a libmime problem?

cc'ing Rich - if this is really a problem with message display, as opposed to database header parsing, he might have an idea.

I need some input from someone who has seen this problem - is it strictly a message display problem, or is it a db header parsing problem? Does anyone need more clarification about the difference?

I'm not sure on this one. Sounds like a possible problem with the smoketest file on the Mac? These files need to be platform specific don't they? I don't see where libmime would loop forever. It will hit the end of the buffer and quit at that point.

About the mesage which causes attempts to load over and over again, it turns out to be the same message which prompted me to file Bug 8899 for Windows client.

Oh, loading over and over was the problem we had with auto detection for charset stuff. Could this be it? - rhp

Could you try looking at the file tempMessage.eml in your temp directory after loading a message and see if that looks OK, please? If that looks OK, then the problem has nothing to do with the db header parsing.

This looks like the right message to me, which is all the DB can help with. I'm not sure who's supposed to do the line conversions (i.e., the code that writes out the message to the temp file, or the code that parses the message from the temp file) but I'm not involved in either of those pieces of code. Anyone know what the right thing to do is? Can someone run the version of 5.0 that actually worked and see what kind of temp file was generated?

There is one differece I noticed when I compared the "tempMessage.eml" generated for the Mac-type linebreak message as opposed to Win-type linebreak for the same message. The .eml file for the latter contained Unix-type "LF" rather than the Mac-type LF.

I didn't mean to write "Mac-type LF". It should have been "Mac-type CR" rather.

thanks for the clarification, but I would expect the windows lines to end with CRLF, not just LF.

The editor I'm using on my Mac can detect all 3 types of line breaks. This is what my editor tells me: Smoketest file for Mac-type: CR .eml file generated from this: CR Smoketest file for Win-tyep: CR+LF .eml file generated from this: LF The Linebreak detection on my editor is pretty accurate and so from the Win-type Smoketest file, we are indeed generating LF-type .eml file

I don't think this is my bug, but in any case, I'm not going to get to it by m8

Sorry, Rich. I don't know who's bug this is, or if it really is a bug, but I'm not doing the bug any favors by leaving it on my list. It could be that libmime needs to deal with non-native line termination.

I'm pretty sure this is the same problem issue for Bug #9231. Marking as duplicate. - rhp *** This bug has been marked as a duplicate of 9231 ***

Kat - since you filed this, I'll let you verify/agree that it's a duplicate of the other bug (which was actually reported later than this one :-)

From the description of 9231 alone, I'm not sure if this bug is a duplicate of that one. Since manifestations of a backend fix can be extensive, I'm inclined to monitor 9231's fix status and check on this one when that one gets fixed. I'll hold off verifying this bug until 9231 is fixed.

** re-checked with 7/22/99 Mac build ** Bug 9231 has been verified/wroksforme since 7/7/99. On today's Mac build, the problem described in this bug still exists. This is proof enough that it is not the same bug as Bug 9231. Re-opning it...

*** Bug 10328 has been marked as a duplicate of this bug. ***

Hello all, I have no clue on this one...nothing with respect to parsing line breaks has changed with libmime so I can't see how this "worked" and then stopped working at some point. mscott: Could something have changed with how we write out the tempMessage.eml file along the way? davidb: This didn't work with 4.5, correct? I have a feeling that we were making it work in the tempMessage.eml creation and that may have changed and now it doesn't work. Comments welcome! In either case, this is getting bumped. - rhp

I don't believe it worked in 4.x. Is anybody claiming that it did?

They are claiming it worked in 5.0, but since libmime parsing is the 4.x code base, it is relavent. - rhp

I don't think it's very relevant that it worked in 5.0 - that may just have been a bug, right? What's really relevant is whether libmime handled non-native line breaks in 4.x. If it hasn't, I can't see a lot of reason to try to change it when we have so many other things to do to get to parity with 4.5

I go back to my original comment posted 06/28/99. Isn't this a restriction that we placed on these files? If this file would break 4.x, then I'm not going out of my way to fix this one. Sorry, but I (like everyone else in the world) has a billion things to do to get anywhere close to the 4.x feature set. If I try to do something here, it will be post B1. - rhp

I concede that the same problem existed on Mac under 4.x -- though Windows client has no problem reading Mac mailboxes. I think it would be nice if direct interchange of mailbox files between different platforms can be done under 5.0. That's why I filed this bug. More important to me would be that our migration/import mailbox utility be able to handle linebreaks when migration occurs from one platform type to another. If this can be accomplished during 5.0, that would be wonderful.

(target milestone is M11 or M12 - add to mail beta tracking bug)

Just tweaking the milestone. - rhp

I'm sure a LOT has changed since this was originally posted (and it was probably fixed along the way), but I copied over my PC formatted smoketest file to the mac and everything seemed to work fine. - rhp

** Checked with 12/17/99 Mac PPC M12 build ** With the above build, I don't have any problem displaying msgs in the PC version of Smoketest file which contains both CR+LF. Mac had this problem throughout 4.x cycles and so this is indeed a very good change. Marking it verified/fixed.