## summary Importing an .eml file into Thunderbird should be lossless/non-destructive, but it is [destructive/datalossy](https://bugzilla.mozilla.org/describekeywords.cgi#dataloss). ## steps to reproduce 0. use a **maildir** mail account (not mbox) 1. import an .eml file via drag+drop from outside Thunderbird into TB's folder pane 2. navigate in a file manager to TB's profile folder\Mail 3. find the newly added .eml file 4. hex-compare the new file *(from step 3)* to the original file *(from step 1)* ## expected results The import should be lossless/non-destructive. The imported .eml file should be preserved 1:1. The file created in TB's profile folder and the original file should be 100% identical. ## actual results The import is destructive/datalossy: * **TB 115** @ Win10/64bit: * appends CRLF (this is bug 1888585) * does not kill 1st line * **TB 128**.0a1 (2024-05-17) (64-bit) @Win10/64bit: * does not append CRLF (so fixes bug 1888585 apparently ?) * but unlike TB115 it kills 1st line (`From`). Regression to TB 115 ? *See the screenshots in the comments below.* ## reiteration / generational loss * in **TB 115**: a repeat of the STR *(i.e. re-importing the file created in step 3 again)* appends yet another CRLF, so the file grows bigger and bigger in size with each iteration ! * in **TB 128**: untested ## relevance * unnecessary and unintended alteration of the data without users' knowledge, who trust their files to be preserved 1:1 ([ux-trust](https://bugzilla.mozilla.org/describekeywords.cgi#ux-trust)) * data-destructive process which should be lossless * since the affected files have changed and are not identical any longer, this bug complicates/impairs : * file deduplication * incremental/differential backup [keywords: extra newline, linefeed]
Bug 1898635 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
## summary Importing an .eml file into Thunderbird should be lossless/non-destructive, but it is [destructive/datalossy](https://bugzilla.mozilla.org/describekeywords.cgi#dataloss). ## steps to reproduce 0. use a **maildir** mail account (not mbox) 1. import an .eml file via drag+drop from outside Thunderbird into TB's folder pane 2. navigate in a file manager to TB's profile folder\Mail 3. find the newly added .eml file 4. hex-compare the new file *(from step 3)* to the original file *(from step 1)* ## expected results The import should be lossless/non-destructive. The imported .eml file should be preserved 1:1. The file created in TB's profile folder and the original file should be 100% identical. ## actual results The import is destructive/datalossy: * **TB 115** @ Win10/64bit: * appends CRLF (this is bug 1888585) * does not kill 1st line * **TB 125**.0b4 @ Win10/64bit * does not append CRLF (so fixes bug 1888585 apparently ?) * but unlike TB115 it kills 1st line (`From`). Regression to TB 115 ? * **TB 128**.0a1 (2024-05-17) (64-bit) @Win10/64bit: * same behavior as reported above for TB 125 *See the screenshots in the comments below.* ## reiteration / generational loss * in **TB 115**: a repeat of the STR *(i.e. re-importing the file created in step 3 again)* appends yet another CRLF, so the file grows bigger and bigger in size with each iteration ! * in **TB 128**: untested ## relevance * unnecessary and unintended alteration of the data without users' knowledge, who trust their files to be preserved 1:1 ([ux-trust](https://bugzilla.mozilla.org/describekeywords.cgi#ux-trust)) * data-destructive process which should be lossless * since the affected files have changed and are not identical any longer, this bug complicates/impairs : * file deduplication * incremental/differential backup [keywords: extra newline, linefeed]
## summary Importing an .eml file into Thunderbird should be lossless/non-destructive, but it is [destructive/datalossy](https://bugzilla.mozilla.org/describekeywords.cgi#dataloss). ## steps to reproduce 0. use a **maildir** mail account (not mbox) 1. import an .eml file via drag+drop from outside Thunderbird into TB's folder pane 2. navigate in a file manager to TB's profile folder\Mail 3. find the newly added .eml file 4. hex-compare the new file *(from step 3)* to the original file *(from step 1)* ## expected results The import should be lossless/non-destructive. The imported .eml file should be preserved 1:1. The file created in TB's profile folder and the original file should be 100% identical. ## actual results The import is destructive/datalossy: * **TB 115** @ Win10/64bit: * appends CRLF (this is bug 1888585) * does not kill 1st line * **TB 125**.0b4 @ Win10/64bit * does not append CRLF (so fixes bug 1888585 apparently ?) * but unlike TB115, it kills 1st line (`From`). Regression to TB 115 ? * **TB 128**.0a1 (2024-05-17) (64-bit) @Win10/64bit: * same behavior as reported above for TB 125 *See the screenshots in the comments below.* ## reiteration / generational loss * in **TB 115**: a repeat of the STR *(i.e. re-importing the file created in step 3 again)* appends yet another CRLF, so the file grows bigger and bigger in size with each iteration ! * in **TB 128**: untested ## relevance * unnecessary and unintended alteration of the data without users' knowledge, who trust their files to be preserved 1:1 ([ux-trust](https://bugzilla.mozilla.org/describekeywords.cgi#ux-trust)) * data-destructive process which should be lossless * since the affected files have changed and are not identical any longer, this bug complicates/impairs : * file deduplication * incremental/differential backup [keywords: extra newline, linefeed]
## summary Importing an .eml file into Thunderbird should be lossless/non-destructive, but it is [destructive/datalossy](https://bugzilla.mozilla.org/describekeywords.cgi#dataloss). ## steps to reproduce 0. use a **maildir** mail account (not mbox) 1. import an .eml file via drag+drop from outside Thunderbird into TB's folder pane 2. navigate in a file manager to TB's profile folder\Mail 3. find the newly added .eml file 4. hex-compare the new file *(from step 3)* to the original file *(from step 1)* ## expected results The import should be lossless/non-destructive. The imported .eml file should be preserved 1:1. The file created in TB's profile folder and the original file should be 100% identical. ## actual results The import is destructive/datalossy: * **TB 115** @ Win10/64bit: * appends CRLF (this is bug 1888585) * does not kill 1st line * **TB 125**.0b4 @ Win10/64bit * does not append CRLF (so fixes bug 1888585 apparently ?) * but unlike TB115, it kills 1st line (`From`). Regression to TB 115 ? * **TB 128**.0a1 (2024-05-17) (64-bit) @Win10/64bit: * same behavior as reported above for TB 125 *See the screenshots in the comments below.* I double-checked all results. ## reiteration / generational loss * in **TB 115**: a repeat of the STR *(i.e. re-importing the file created in step 3 again)* appends yet another CRLF, so the file grows bigger and bigger in size with each iteration ! * in **TB 128**: untested ## relevance * unnecessary and unintended alteration of the data without users' knowledge, who trust their files to be preserved 1:1 ([ux-trust](https://bugzilla.mozilla.org/describekeywords.cgi#ux-trust)) * data-destructive process which should be lossless * since the affected files have changed and are not identical any longer, this bug complicates/impairs : * file deduplication * incremental/differential backup [keywords: extra newline, linefeed]