User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20090909 Fedora/3.5.3-1.fc11 Firefox/3.5.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 I receive git generated patch messages with UNIX line endings. When I try to save it - result file has line endings converted to DOS style (It is highly not wished). When I go to message source and try to save it there - result file has original line endings - it proves silent conversion. I don't see the point of doing it - but if some people wish to have such conversion - it should be optional. Reproducible: Always Actual Results: *.eml file with converted line endings Expected Results: *.eml file with original message source
mst, do you still see this problem?
yes I do My current version ID: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7
(In reply to comment #0) > Actual Results: > *.eml file with converted line endings > Expected Results: > *.eml file with original message source .eml file extention is for copy of "mail data stream deined by SMTP, POP3, IMAP", so keeping new line character in the "mail data stream deined by SMTP, POP3, IMAP" upon "Save As, .eml" of email is desired behavior. On the other hand, save at View/Message Source window you did is "save of shown mail source in HTML by mail source viewer==HTML viewer" and is as follows. - Mail data stream in mail folder file is shown as <pre> of HTML. - Upon save, new line character of system is used, because save of text data. - If .eml is specified, file extention of .eml is perhaps merely added. Original mail data stream is already lost by convertion to HTML. This difference is similr to next in browser. (a) Save link target as: Downloaded data obtained by HTTP GET is saved as-is. This is similar to "Save As" of email of Tb. (b) View/Message Source, Save: Same as "View/Message Source, Save", so difference of new line character, difference of number of null lines, etc. from (a) may occur. (c) Save page as, HTML: As seen in "Web Page, complete", HTML is altered upon save. (d) View Selection Source, Save, HTML: Saved HTML is re-constructed from DOM. Please note that .eml file can be seen as text file, but it's never merely a text file. In any save, IIRC, Tb uses new line character of system if save in text mode(.txt, .html, ...) On linux, I believe dos2unix command is shipped by many distoro's (see man dos2unix). I can't think who receives "patch messages" can't use dos2unix. I guess user of the saved .eml is not you, script or program uses it. If so, inserting dos2unix step in script is simlest/easiest solution. I believe mail data corruption in some cases is far bigger problem. - Original is digital signed mail, with one of CRLF, LF, CR, or mixture. - Tb saves in .eml with LF(converts CRLF, CRLF to LF as you want) - Import the .eml to Tb => There is no way to know original new line char => mail is currupted, if different new line char from original Change from CRLF to LF in .eml should be done by user himself with his own risk, intead of by Tb as mailer. > but if some people wish to have such conversion - it should be optional. Tb doesn't do conversion to CRLF upon save to .eml. Tb keeps as-is. As Severity is not Enhancement, this bug is INVALID. If Severity is Enhancement(option to conver CRLF to LF upon save to .eml), I believe proper request, but I think WONTFIX is reasonable, because dos2unix exists.
> patch messages If patch is attached as text file, I gues no problem. So, I guess the patch text is sent in mail body of text message. Can "Save As, .txt" be solution? (if saved as .txt, saved with LF on Linux) File extention of .eml and message headers in saved file mandatory in your case?
bienvenu, see comment 3
I hit this issue in bug #765675.
git-format-patch outputs mbox format, but Thunderbird outputs the message as eml file. As far as I can investigate there is no definition about the line ending codes in eml format unfortunately. See discussion in bug 503271.