1716651 - Copying a message on a maildir-backed account adds an extra trailing '\n'

Status: RESOLVED WORKSFORME

(MailNews Core :: Backend, defect)

Description

[Ben Campbell]

This is something I encountered in Bug 1714277 - with an mbox store, the message copies across verbatim, but under maildir it gains a '\n'.

I'm working around it in my update of test_copyToInvalidDB.js (in Bug 1714277). I add a .trim() when I compare message texts. So any fix here should remove the .trim() hack there.

To replicate (once the Bug 1714277 patch has landed), change the compare at the bottom of the test:

-Assert.equal(gotMsg.trim(), expectedMsg.trim());
+Assert.equal(gotMsg, expectedMsg);

... set maildir set as the default store:

storage.pref("mail.serverDefaultStoreContractID", "@mozilla.org/msgstore/berkeleystore;1");

...and run the test:

./mach xpcshell-test comm/mailnews/base/test/unit/test_copyToInvalidDB.js

Comment 1

[José M. Muñoz]

with an mbox store, the message copies across verbatim, ...

That wasn't always the case, see bug 1427732.

Comment 3

[chrizilla]

Ben, if you are still working on a fix, could you verify if it also solves bug#1888585 which allegedly is a dupe ?
I am not sure if it's really the same problem, because I report an appended CRLF (\r\n) whereas you only mention a single \n.
Other difference: My reported problem results from importing whereas you are talking about copying here.

Comment 4

[Ben Campbell]

It's possible this bug is already fixed by Bug 1719121, but I haven't had time give maildir a good tire-kicking yet.
I think Bug 17179121 should also fix the import-from-file case.
But I do think there might possibly still be some glitches with other importers (eg from outlook), which make their own assumptions about mbox (which is the cause of the bulk of the maildir issues).

Comment 5

[Magnus Melin [:mkmelin]]

chrizilla: are you able to check beta?

Comment 6

[chrizilla]

Ben+Magnus, thank you.
Good news: I can confirm that in 125.0b4 the problem I reported in bug 1888585 does not occur anymore. Nothing is appended at the end: neither a \r\n nor a single \n.
This probably means the bug is fixed ? If so, if bug 1888585 truly is a duplicate of bug 1716651, doesn't this mean, the latter would have to be closed as fixed as well ?

Bad news is, there seems to be a regression:
While TB115 suffers from the appended CRLF bug, it doesn't otherwise modify the imported file.
However TB125.0b4 strips the first line (envelope) from the file. TB115 didn't do that.
What should I do ? File a bug for that apparent regression ?

Comment 7

[Magnus Melin [:mkmelin]]

Bug 1888585 was resolved, as duplicate of this one - no need to do anything further.

Not writing out "From" first line for mbox is expected. If anything else, file a new bug for issues.