1174489 - Repeated downloads of Yahoo account Inbox and duplicate mail stored in INBOX file, due to Yahoo ISP problems and instability.

Status: RESOLVED INVALID

(Thunderbird :: Folder and Message Lists, defect)

Description

[nathanielmbeaver]

Attachment: expected-inbox-size.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.7.0
Build ID: 20150513015018

Steps to reproduce:

Make a clean profile, set up IMAP mail account. Leave Thunderbird running a few days.

This bug has been reproduced on Windows 7 with the old stable release (31.6.0), beta (38.0), and Earlybird (40.0).


Actual results:

Thunderbird downloads inbox repeatedly, and stores duplicated messages in the INBOX file.

This means that the size of the actual INBOX file is several times as large as the nominal size that Thunderbird calculates. Specifically, Thunderbird reports the inbox as 983 MB, but the actual filesize is 2925690702 bytes (2.8 GB).

$ du -h INBOX-1
2.8G    INBOX-1
$ du --bytes INBOX-1
2925690702      INBOX-1

The duplicate messages can be observed by paging through for duplicates with `less` or by grepping a date of a message.

$ grep -n 'Date: Sun, 12 Feb 2012 18:17:19 -0800 (PST)' INBOX-1
159154:Date: Sun, 12 Feb 2012 18:17:19 -0800 (PST)
15432936:Date: Sun, 12 Feb 2012 18:17:19 -0800 (PST)
29359304:Date: Sun, 12 Feb 2012 18:17:19 -0800 (PST)


Expected results:

Inbox does not re-download old messages and actual size of INBOX file matches nominal size.

Comment 1

[Wayne Mery (:wsmwk)]

This is a wide reported yahoo problem. Annoying, but not caused by thunderbird

Comment 2

[nathanielmbeaver]

If the size of the inbox file does not match the size of the inbox, that is a bug in Thunderbird.

More generally, how do you know for sure it is restricted to Yahoo?

Comment 3

[Matt]

Right click the folder, select compact.  Now they match in size.

Comment 4

[Wayne Mery (:wsmwk)]

Thunderbird can only show what yahoo's imap stream tells Thunderbird about the mail it has available to show - that's the way imap works.

The fact that the Yahoo web interface shows more messages than Thunderbird doesn't change the fact that the imap protocol decies what is shown in Thunderbird.

Unfortunately, yahoo has bugs and is currently AFU as numerous support topics are telling us.  If yahoo fixes their stuff and you still have a problem, then we have something worth investigating. But for now, we do not.

Comment 5

[nathanielmbeaver]

(In reply to Matt from comment #3)
> Right click the folder, select compact.  Now they match in size.

Alas, they do not.

This was one of the first things I tried, and it does not change the size of the INBOX file or eliminate the duplicate messages.

Even if it did, that would only temporarily address the symptom, not the root cause.

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
> Thunderbird can only show what yahoo's imap stream tells Thunderbird about
> the mail it has available to show - that's the way imap works.

I agree that we need to know what is going on between Thunderbird and Yahoo's IMAP servers; I will see if I can get a good IMAP protocol log and post it in the next few days.

> 
> The fact that the Yahoo web interface shows more messages than Thunderbird
> doesn't change the fact that the imap protocol decies what is shown in
> Thunderbird.

The discrepancy is between Thunderbird's own "Size on disk" calculation and the actual size of the INBOX file in the profile folder, not between the Yahoo web interface and Thunderbird.

> 
> Unfortunately, yahoo has bugs and is currently AFU as numerous support
> topics are telling us.  If yahoo fixes their stuff and you still have a
> problem, then we have something worth investigating. But for now, we do not.

I understand that it appears that Yahoo's servers are at fault here, but we need a clearer understanding of what's going on than "yahoo has bugs and is currently AFU".

I would appreciate it if you would refrain from resolving the bug until we know more from the IMAP logs or until we can establish that this is a duplicate of an earlier bug.

For example, these bugs are reported against Yahoo's IMAP servers, but were not closed as invalid:

https://bugzilla.mozilla.org/show_bug.cgi?id=610264

https://bugzilla.mozilla.org/show_bug.cgi?id=661510

https://bugzilla.mozilla.org/show_bug.cgi?id=985166

Comment 6

[Sören Hentzschel]

FWIW, other clients have the same problem. I can confirm the "Repeated downloads of Yahoo account Inbox" problem with Thunderbird and with Apple Mail.

Comment 8

[Botond Ballo [:botond]]

I have this problem too. I just realized my INBOX file is currently 6.3 GB, when it should be 350 MB - yikes!

If this is a problem on Yahoo's side, what can we do to report the problem to them? What is the appropriate forum, and what information should we provide them?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Botond Ballo [:botond] from comment #8)
> I have this problem too. I just realized my INBOX file is currently 6.3 GB,
> when it should be 350 MB - yikes!

Is it leaving multiple copies of messages in your Inbox?

> If this is a problem on Yahoo's side, what can we do to report the problem
> to them? What is the appropriate forum, and what information should we
> provide them?

Call them incessently? 

here is one support report -- https://community.bt.com/t5/Email/IMAP-changed-to-200-message-limit/td-p/1493808

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to nathanielmbeaver from comment #5)
>...
> For example, these bugs are reported against Yahoo's IMAP servers, but were
> not closed as invalid:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=610264
> https://bugzilla.mozilla.org/show_bug.cgi?id=661510
> https://bugzilla.mozilla.org/show_bug.cgi?id=985166

Because they are not invalid, as far as we know.

However, in the case of this bug report the best information we have is that the redownloading problem originates with Yahoo and is solvable only by Yahoo, and is reported by multiple email clients.  This part of the bug report is not actionable or preventable by Thunderbird.

A few of the reports in SUMO:
https://support.mozilla.org/en-US/questions/1066716
https://support.mozilla.org/en-US/questions/1066717
https://support.mozilla.org/en-US/questions/1066713
https://support.mozilla.org/en-US/questions/1066756
https://support.mozilla.org/en-US/questions/1066735
https://support.mozilla.org/en-US/questions/1066698

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to nathanielmbeaver from comment #0)
> ...
> This bug has been reproduced on Windows 7 with the old stable release
> (31.6.0), beta (38.0), and Earlybird (40.0).
>  
> Actual results:
> 
> Thunderbird downloads inbox repeatedly, and stores duplicated messages in
> the INBOX file.
> 
> This means that the size of the actual INBOX file is several times as large
> as the nominal size that Thunderbird calculates. Specifically, Thunderbird
> reports the inbox as 983 MB, but the actual filesize is 2925690702 bytes
> (2.8 GB).
> 
> $ du -h INBOX-1
> 2.8G    INBOX-1
> $ du --bytes INBOX-1
> 2925690702      INBOX-1
> .. 
> 
> Expected results:
> 
> ... actual size of INBOX file matches nominal size.

Aceman, do we have any open bug reports of this sort?

Comment 12

[:aceman]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
> Thunderbird can only show what yahoo's imap stream tells Thunderbird about
> the mail it has available to show - that's the way imap works.
> 
> The fact that the Yahoo web interface shows more messages than Thunderbird
> doesn't change the fact that the imap protocol decies what is shown in
> Thunderbird.

It depends on what we actually want to show in TB as the folder size. Whether it is the reported size on the server or the size of the mbox file on disk (containing only the cached message bodies, possibly not all if sync/offline is not set for the folder).
It seems this one and also bug 786022 say it shows the size on server. Whether that is "as designed" or a bug is outside of my knowledge.

Comment 13

[Wayne Mery (:wsmwk)]

Right. And multiple downloads of messages means the file size will be large. This is to be expected.  

A compact should resolve that by getting rid of the "old" messages, unless thunderbird doesn't think the "old" messages are "deleted"?  And if compact does not help then I would hope properties | repair does what's needed

Comment 14

[David Lechner (:dlech)]

It sounds to me like this should be split into 3 bugs.

1. This bug: Yahoo causes multiple offline copies of a message to be stored locally.
2. Bug 786022: The "Size on disk:" label is ambiguous (see attachment 8622029 [details]). Is it the disk on the server or the local computer? Based on this discussion, it sounds like it is the size on the server, so the label should read "Size on server:" instead. 
3. New bug (feature request): Size of per folder offline storage is not available in user interface. This should be added immediately below the "Size on server:" label so that the values can be easily compared. It should have a label of "Size on local disk:". If offline storage/synchronization is disabled, this label should be grayed out.

Comment 15

[Kent James (:rkent)]

(In reply to David Lechner (:dlech) from comment #14)
> 2. Bug 786022: The "Size on disk:" label is ambiguous (see attachment
> 8622029 [details]). Is it the disk on the server or the local computer?
> Based on this discussion, it sounds like it is the size on the server, so
> the label should read "Size on server:" instead. 

In my work in Bug 1032360 I started to address the ambiguity between size of server storage versus local storage, but it is a very difficult problem because the concepts are conflated in the codebase.

Comment 16

[Christian Riechers]

(In reply to David Lechner (:dlech) from comment #14)
> 3. New bug (feature request): Size of per folder offline storage is not
> available in user interface.

This extension shows the size of a folder on local disk and the size on the server for IMAP accounts.
https://nic-nac-project.org/~kaosmos/index-en.html#foldersize
Looks like it has not been updated for ages, but it still works.

Comment 17

[nathanielmbeaver]

I couldn't find a way to do a meaningful comparison between the logs when the problem was occurring and when it wasn't.

Also, the logs were not amenable to anonymization, as sometimes potentially useful information followed "ReadNextLine" and "CreateNewLineFromSocket" and sometimes just the plain text of email, which also appeared spread out across the log files. I wasn't able to anonymize them by hand as they were several gigabytes in size.

In any case, the issue no longer seems to occur. I can only hope it won't relapse.

Comment 18

[Botond Ballo [:botond]]

(In reply to nathanielmbeaver from comment #17)
> In any case, the issue no longer seems to occur. I can only hope it won't
> relapse.

I still experience this problem. My inbox file on disk is 9 GB and growing :(

Comment 19

[nathanielmbeaver]

Hm, that is unfortunate. I'm out of ideas, but I'll leave the bug as unconfirmed for now.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to nathanielmbeaver from comment #5)
>...
> For example, these bugs are reported against Yahoo's IMAP servers, but were
> not closed as invalid:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=610264

BTW this was identified per a protocol log. Without your protocol log it's near impossible to help you.

Comment 21

[WADA:World Anti-bad-Duping Agency]

To bug opener:

What is actual environment? IMAP? POP3?
What phenomeno do you call "duplicate mail stored"?
Whaat phenomenon do you call by "downloads inbox repeatedly"?
> Actual results:
> Thunderbird downloads inbox repeatedly, and stores duplicated messages in the INBOX file.

If imap, UID of a mail is unieque at server, so even if "Fetch of all mail's headers" and/or "Download by auto-sync" somehow done multiple times, "Duplicate mail" won't occur.
If imap and "Download by auto-sync" is executed multiple times, it's merely keeps garbled data of previously download mail data, and it should be freed by Compact, as said in comment #3.
> Right click the folder, select compact.  Now they match in size.
Did you actually do Compact?

If imap and problem is file size of file named Inbox(not Inbox.msf), stop auto-sync of Inbox folder first.
  Folder Properties/Synchronization.
And show "Order Received column"(vaalue is UID of mail if IMAP), and sort by "Order Received" column.
Is "Duplicate UID" like phenomenon seen? (it's usually never happen if imap)
Is "Duplicate mail"(absolutely same content but UID is different) seen? (it's usually never happen if imap)
"Duplicate mail"(absolutely same content but different Received column value==Offset of mail) happens only when POP3.

(In reply to Botond Ballo [:botond] from comment #8)
> I have this problem too. I just realized my INBOX file is currently 6.3 GB,
> when it should be 350 MB - yikes!

"Offline-Store file > 4GB" is supported in imap, but Compact of Offline-Store file may fail if larger than 4GB. Compact might have issue when "file size > 2GB" if Linux or Mac OS X.

If imap, "Split Mbox" is pretty easy.
  Create Inbox2, then move many mails in Inbox to Inbox2.
  What Tb does to is "uid move mm:nn Inbox2" only(when move is supported), then fetch moved mails in Inbox2.
  All actions for "Move mails" is done by server.
  To avoid auto-sync of Inbox2, set Offline-Use=Off for Inbox2(Folder Properties/Synchronization)
  If "it should be merely 350 MB", "move all mails from Inbox to Inbox2" is better.  
Is Compact normally executed?

Comment 22

[Botond Ballo [:botond]]

(In reply to WADA from comment #21)
> (In reply to Botond Ballo [:botond] from comment #8)
> > I have this problem too. I just realized my INBOX file is currently 6.3 GB,
> > when it should be 350 MB - yikes!
> 
> "Offline-Store file > 4GB" is supported in imap, but Compact of
> Offline-Store file may fail if larger than 4GB. Compact might have issue
> when "file size > 2GB" if Linux or Mac OS X.
> 
> If imap, "Split Mbox" is pretty easy.
>   Create Inbox2, then move many mails in Inbox to Inbox2.
>   What Tb does to is "uid move mm:nn Inbox2" only(when move is supported),
> then fetch moved mails in Inbox2.
>   All actions for "Move mails" is done by server.
>   To avoid auto-sync of Inbox2, set Offline-Use=Off for Inbox2(Folder
> Properties/Synchronization)
>   If "it should be merely 350 MB", "move all mails from Inbox to Inbox2" is
> better.  
> Is Compact normally executed?

When I say my INBOX file should only be 350 MB in size, I mean that's the space required to store all the emails in my inbox. That's what the size of the INBOX file was before Thunderbird started downloading all the emails over and over again, resulting in an ever-growing (currently 9 GB and counting) INBOX file.

Comment 23

[WADA:World Anti-bad-Duping Agency]

(In reply to Botond Ballo [:botond] from comment #22)
> When I say my INBOX file should only be 350 MB in size, I mean that's the
> space required to store all the emails in my inbox. That's what the size of
> the INBOX file was before Thunderbird started downloading all the emails
> over and over again, resulting in an ever-growing (currently 9 GB and
> counting) INBOX file.

This is pretty normal state, if download for auto-sync is executed multiple times.
  Delete Inbox.msf, then open Inbox
  => Because sync'ed state is lost, all mail is downloaded again, and data is appended to file named Inbox.
Wasted space by non-referred data in file named Inbox should be freed by Compact as written in comment #3.
Because question relevant to Compact and comment #3 is already written in this bug, I can't imagine "Compact is never tried yet" in your case.
So, I suspected "Compact fails, or not invoked, even when Compact is explicitly requested" in your case.

Comment 24

[Botond Ballo [:botond]]

Hmm, I actually haven't tried compacting before. I tried it now and it reduced my INBOX file's size to 410 MB, which looks reasonable.

However, I don't understand why this is a "normal state". Why does Thunderbird re-download already downloaded mail multiple times? Even if the disk space is reclaimed by compacting, isn't it a lot of unnecessary wasted bandwidth?

Comment 25

[WADA:World Anti-bad-Duping Agency]

(In reply to Botond Ballo [:botond] from comment #24)
> However, I don't understand why this is a "normal state".

If "delete of mails" occurs in Inbox, (b) "Total mail data size in Inbox << file size of file named Inbox" is pretty normal state, because "data of deleted mail" is not removed until Compact is invoked. This is current design/implementation,
If (a) "download of all mails by auto-sync is somehow executed again" happens, 
(b) "Total mail data size in Inbox" << file size of file named Inbox" is pretty normal state just after problem (a) happened, because mail data is appended to file named Inbox when problem (a) happened.
Note: This state of (b) is pretty easily produced by "Intentional delete Inbox.msf file".
State of (b) should disppear by "Compact of Offline-Store file named Inbox" sooner or later.

Compact is invoked by;
(i)   Auto-Compact,
(ii)  Compact Folders
      (Compact of all folders of owner account of selected folders at folder pane, except imap/nntp. RSS too?)
(iii) Compact(this folder)
Note-1: (ii) is current design/implementation.
        When imap, do (iii) instead of (ii) if you always tried (ii). 
Note-2: I don't know about Compact on Unified Folder,
        If you do Compact at View/Folder/Unified, do Compact on each actual folder, or do at View/Folder/All.
IIRC, if "Repair Folder" is requested, recent Tb discarded old content in file named Inbox, and started from fileSize of Inbox=ZERO instead of "append data", although I'm not sure.

Please don't mix multiple issues in this bug.
(a) "download of all mails by auto-sync is somehow eecuted again", (c) "Auto-Compact is somehow not invoked", (d) "Manual Compact(this folder) doesn't work", are different problems, even if same phenoenon of (b) is involved in all cases.
Bug summary obviously state that this bug is for problem of (a) and for problem of (a) only.
Please surely rule out problem like (c) / (d) from this bug.

Anyway, Compact worked pretty well in your case(data size=350MB, fileSize=9GB).
So, problem of (d) has been surely ruled out in your case.
Outstaaanding problem is (a) and (b) in your case.
Go ahead and continue trouble shooting, and post comments at appropriate bug for outstanding problem, please.

Comment 26

[WADA:World Anti-bad-Duping Agency]

Sorry, typo.
Outstaaanding problem is (a) and (c) in your case.

Comment 27

[WADA:World Anti-bad-Duping Agency]

FYI.
IIRC, bug for phenomenon like next exists, although I'm not sure.
  Auto-Compact of imap folder is not executed, if "expunge atfer each delete a mail" is used.
Because auto-compact relies on "total deleted mail data size at folder", I suspect that "total deleted mail data size at folder" is reset by "expunge atfer each delete a mail". By EXPUNGE, all mail flagged as \Deleted is removed/erased at imap server, so, upon next Mbox open(fetch flag of all existent UID is done), Tb knows "total deleted mail data size of this Mbox=ZERO at server".  
And, because "invoking auto-compact" relies on "Total deleted mail data size in Tb", if imap accounts only and if mail delete(including delete by move) doesn't occur at Local Folders, auto-compact may not be invoked.

Comment 28

[WADA:World Anti-bad-Duping Agency]

IUUC, Yahoo! IMAP is officially service for mobile device, and Yahoo! still doesn't announce official support of mail client of PC, even though Yahoo! never rejects access from mail client of PC.
So, some limitations existed, for example, max 5000 UIDs in one uid fetch command. I don't know such limitation still exists.

1GB Inbox is normal in mobile device world like smart phone or touch pad device?
How many mails do you keep in Inbox?

There is no need to keep all mails in Mobx named Inbox. Because of IMAP, any Mbox can be created.  
To bug opener.
1. Create InboxA(Offline-Use=Off), move all mails in Inbox to InboxA.
2. Compact of Inbox. What occurs?
3. Repair Folder of Inbox. What occurs.
4. Create InboxB(Offline-Use=Off). In daily use, if mail is read, move read mail to InboxB.
   Do you see you problem?
5. After problem disppeared, set Offline-Use=On of InboxB. Problem occurs?
6. After it, set Offline-Use=On of InboxA. Problem occurs?

Comment 29

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
> The fact that the Yahoo web interface shows more messages than Thunderbird
> doesn't change the fact that the imap protocol decies what is shown in Thunderbird.

Wayne, I can't find (x) "The fact that the Yahoo web interface shows more messages than Thunderbird" in this bug.
Where does the (x) come from? Is it bug opener's case?

Comment 30

[Wayne Mery (:wsmwk)]

(In reply to WADA from comment #29)
> (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
> > The fact that the Yahoo web interface shows more messages than Thunderbird
> > doesn't change the fact that the imap protocol decies what is shown in Thunderbird.
> 
> Wayne, I can't find (x) "The fact that the Yahoo web interface shows more
> messages than Thunderbird" in this bug.
> Where does the (x) come from? 
Is what the user claims, not me.

> Is it bug opener's case?
I don't know, and I don't think we can tell without examining protocol log - and I guess we need a shorter one.

Comment 31

[nathanielmbeaver]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #30)
> (In reply to WADA from comment #29)
> > (In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #4)
> > > The fact that the Yahoo web interface shows more messages than Thunderbird
> > > doesn't change the fact that the imap protocol decies what is shown in Thunderbird.
> > 
> > Wayne, I can't find (x) "The fact that the Yahoo web interface shows more
> > messages than Thunderbird" in this bug.
> > Where does the (x) come from? 
> Is what the user claims, not me.

I'm confused. Which user claimed that?

The Yahoo web interface has always matched what Thunderbird says, but sometimes the size of the actual INBOX file is larger, because there are duplicates that Thunderbird doesn't count.

> 
> > Is it bug opener's case?
> I don't know, and I don't think we can tell without examining protocol log -
> and I guess we need a shorter one.

I can't reproduce this bug anymore, so I cannot provide such a log.

Even if I could reproduce, it was an intermittent problem, so I could not choose the size of the protocol log.

If I could get some recommendations on what specifically to look for in the IMAP log, that would be tremendously helpful.

For example, of the 83980651 lines in the logfile, 83873200 (99.9%) contain the string 'ReadNextLine' and look like this:

5280[ed1d360]: ReadNextLine [stream=114f7920 nb=271 needmore=0]

If these are not important, that would narrow things down considerably.

As for repairing and compacting, these did sometimes remove the duplicate messages, but only temporarily.

In particular, compacting seemed to immediately eliminate the duplicate messages on Linux, but not Windows 7. It may have been a version mismatch or something else, though; I don't have sufficient data to be sure, and I can't get any more now.

Comment 32

[WADA:World Anti-bad-Duping Agency]

(In reply to nathanielmbeaver from comment #31)
> I can't reproduce this bug anymore, so I cannot provide such a log.

Closing as INCOMPLETE per comment.

Comment 33

[nathanielmbeaver]

Please do not resolve as INCOMPLETE just yet. Botond Ballo can still reproduce, as far as I know.

Are the "ReadNextLine" parts of IMAP log file important? It's 13MB without those lines, but 4.9 GB with them (hence the high compression ratio).

Comment 34

[Wayne Mery (:wsmwk)]

To Botond ...

(In reply to Botond Ballo [:botond] from comment #24)
> Hmm, I actually haven't tried compacting before. I tried it now and it
> reduced my INBOX file's size to 410 MB, which looks reasonable.
> 
> However, I don't understand why this is a "normal state". Why does
> Thunderbird re-download already downloaded mail multiple times? Even if the
> disk space is reclaimed by compacting, isn't it a lot of unnecessary wasted
> bandwidth?

likely because yahoo is telling thunderbird in the imap traffic that the duplicate messages are not the same as the ones already downloaded, i.e. the probably have different UID. In such cases, Thunderbird is required do download the additional messages.

afaik, we're not seeing this problem for non-yahoo servers. Are you?

Comment 35

[nathanielmbeaver]

Attachment: IMAP log file, zipped

I have attached the requested IMAP log file with the 'ReadNextLine' parts removed. The portions of plaintext email between lines containing 'Begin Message Download Stream' and 'Normal Message End Download Stream' have also been removed.

I did not redact lines such as 'dG2N5Zj0MGN59dselWfi8=' or 'h3mVQaiQtXeQ92mHaveLTY_KzD3ML55fxcaKJ2e0K.HVhIGZ10c5CAr2USoJ8weUIqVtg8Mw.zfuakBTQA--', as they do not appear to contain personal information and may be useful.

The unzipped size of the file is 11MB; I hope that is satisfactory.

Comment 36

[WADA:World Anti-bad-Duping Agency]

(In reply to nathanielmbeaver from comment #35)
> IMAP log file, zipped

Which part is "evidense of Repeated downloads"?

If UID of each mail is not changed by Yahoo!, following should be logged.
  1. For UID=AAA to BBB, download(fetch of body) should be logged.
  2. Between 1 and 3, something occurs. 
  3. For same UID=AAA to BBB, download(fetch of body) should be logged.
If UID of each mail is changed by Yahoo!, following may be logged.
  4. For UID=AAA to BBB, download(fetch of body) should be logged.
  5. Between 1 and 3, UIDVALIDTY may be changed by server.
  6. For same UID=AAA to BBB or different UID=XXX to YYY, download(fetch of body) should be logged.

Which part(line) of log corresponds to which part of above flow?

Comment 37

[Phoenix]

Nathaniel, please respond on Comment 36

Comment 38

[nathanielmbeaver]

The logfile has no timestamps, so I can't point to a particular part of the logfile and say "that was where it was re-downloading the inbox".

I was following the directions here:

https://wiki.mozilla.org/MailNews:Logging#Windows

The default batch file does not include timestamps, and there's no point in getting a new logfile with timestamps because I can't reproduce anymore.

If the IMAP logfile gives no insight into what was going on and Botond Ballo can't reproduce either, I am in favor of closing this bug as invalid.

Comment 39

[WADA:World Anti-bad-Duping Agency]

INVALID per comment #38.

Comment 40

[WADA:World Anti-bad-Duping Agency]

(In reply to nathanielmbeaver from comment #38)
> I was following the directions here:
> https://wiki.mozilla.org/MailNews:Logging#Windows
> The default batch file does not include timestamps, 
> and there's no point in getting a new logfile with timestamps because I can't reproduce anymore.

What is "default batch file" in the document? Where can we find the "default batch file" in the domument?
It's an example for ease of understandig setting, isn't it?
As for timestamp which is optional(but recommended) parmeter, it's surely stated in "2 Environment Variables to set" which is placed at pretty top part of the document.
Even if general user, I believe that peoples usualy read pointed document especially when it's a kind of manual.
Is it wrong?

A reason why timestamp is not written in example of bat file is:
  timestamp was an enhancement which was implemented after requesting for long time.
  When the document was updated by *VOLUNTEER* people,
  as easily known by description in the "2 Environment Variables to set",
  It was released in Beta build only.
If you think timestamp is better written in example of bat file for majority of users, please update the document by yourself or requst update of the document, instead of posting comment of complint in bug at B.M.O, please.