On Wed, Jun 13 2012, Jesse Rosenthal wrote:
> Previously, the timestamp at the beginning of the FCC maildir unique
> maildir name was derived incorrectly, thanks to an integer
> overflow. This changes the derivation of timestamp to float
> arithmetic, and so gets the number correct. (It is still
Hi,
thanks for thinking this through.
On Thu, 14 Jun 2012, Tomi Ollila wrote:
> Alternatives:
>
> 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit
> systems.
Well, that assumes there is still the same arithmetic operations -- the
calendar issue will probably push them to e
Hi,
thanks for thinking this through.
On Thu, 14 Jun 2012, Tomi Ollila wrote:
> Alternatives:
>
> 1) Use current patch, filenames will have extra '-' in 2038 on 32-bit
> systems.
Well, that assumes there is still the same arithmetic operations -- the
calendar issue will probably push them to e
On Wed, Jun 13 2012, Jesse Rosenthal wrote:
> Previously, the timestamp at the beginning of the FCC maildir unique
> maildir name was derived incorrectly, thanks to an integer
> overflow. This changes the derivation of timestamp to float
> arithmetic, and so gets the number correct. (It is still
Previously, the timestamp at the beginning of the FCC maildir unique
maildir name was derived incorrectly, thanks to an integer
overflow. This changes the derivation of timestamp to float
arithmetic, and so gets the number correct. (It is still formatted
with "%d" so it will show up as an integer.
Previously, the timestamp at the beginning of the FCC maildir unique
maildir name was derived incorrectly, thanks to an integer
overflow. This changes the derivation of timestamp to float
arithmetic, and so gets the number correct. (It is still formatted
with "%d" so it will show up as an integer.