There are some variables in nsPop3Protocol.h like m_totalDownloadSize, that are int32_t. Once we support 4GB+ folders, we should be able to download more than 4GB of messages in total in a row. So these variables need to be bumped to int64_t and the code using them inspected if they aren't used in 32bit arithmetics somewhere.

"Once we support 4GB+ folders, we should be able to download more than 4GB of messages in total in a row." is true, but that does not mean that it blocks progress on 64bit keys. Removing the blocking.

There is no work on 64bit keys. The bug you removed was the meta bug that will expose 64bit folder size to the users (by allowing message stores to accept growing beyond 4GB as the last step). If we advertise 4GB+ folders before the bug here is fixed, a user attempting to download more than 4GB will probably silently fail with unknown reasons. Unless we add new code that rejects such a big download. Instead of just fixing this bug. So I think the blocking was properly set.

"If we advertise 4GB+ folders before the bug here is fixed, a user attempting to download more than 4GB will probably silently fail with unknown reasons." My sense is that this is enough of an edge case that we would advertise 64bit keys even with this known issue.

(In reply to Kent James (:rkent) from comment #3) > My sense is that this is enough of an edge case that we would advertise > 64bit keys even with this known issue. There are no 64bit keys. If you mean 64bit folders, then it is questionable if this is an edge case. Yes, users will probably not download 4GB+ emails from POP3 as a common daily occurence. But e.g. when installing TB (or reinstalling or debugging TB problems), setting up an account and connect to a server that will initially offer 4GB+ messages may be a more common use case (e.g. if somebody has the space on a POP3 server to keep all messages there). 2 GB mailboxes are common here. Gmail (accessible via POP3) offers more than 4GB. Anyway, this shouldn't be hard to do to justify pushing it out to future.

Try run: https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=f39fdb9ddb01

Comment on attachment 8691058 [details] [diff] [review] patch >- void UpdateProgressPercent (uint32_t totalDone, uint32_t total); >+ void UpdateProgressPercent(uint64_t totalDone, uint64_t total); This needs to be int64_t like everything else. r=me with that fixed. >- int32_t m_bytesInMsgReceived; >+ int32_t m_bytesInMsgReceived; Ugh, for a second I thought you had changed this to int64_t too :-\

(In reply to neil@parkwaycc.co.uk from comment #6) > >- int32_t m_bytesInMsgReceived; > >+ int32_t m_bytesInMsgReceived; > Ugh, for a second I thought you had changed this to int64_t too :-\ We do not support a single message of 4GB+ yet and there would be quite some work to do that.

https://hg.mozilla.org/comm-central/rev/9a16c9bd1ec1cae17426609eef3fbdebfe882b70 Bug 1093299 - Promote m_total* variables in nsPop3Protocol.h to int64_t to allow downloading 4GB+ of messages via POP3. r=Neil