On Tue, Feb 1, 2011 at 11:52 AM, erik quanstrom wrote:
> On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote:
>> in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
>> started acme. at some point, the acme window disappeared. newly
>> received messages in my gmail inbo
On Tue Feb 1 12:32:34 EST 2011, stanley.lie...@gmail.com wrote:
> in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
> started acme. at some point, the acme window disappeared. newly
> received messages in my gmail inbox continue to get marked as read
> shortly after they arrive.
in plan 9: using upas/fs, i mounted my gmail inbox over imap, then
started acme. at some point, the acme window disappeared. newly
received messages in my gmail inbox continue to get marked as read
shortly after they arrive. my assumption is that upas/fs is still
accessing the mailbox. how can
On 2008-Jun-11, at 19:31 , erik quanstrom wrote:
right. since the date is attached when delivered to a mailbox,
why doesn't this date change when it's delivered to a secondary
mailbox? why is the assignment a magical property of the inbox?
Most likely it's just an artifact of the original U
>> by the way, does anyone know the rationale for the date on the
>> unix "From " line? upas sets it to the date the message is originally
>> delivered to the inbox. moving it from the inbox to another folder
>> does not change the date.
>
> the date is the date it was delivered.
> it's a receiv
> by the way, does anyone know the rational for the date on the
> unix "From " line? upas sets it to the date the message is originally
> delivered to the inbox. moving it from the inbox to another folder
> does not change the date.
the date is the date it was delivered.
it's a receiver-side pos
is there any reason that upas/fs does rfc2047 translation for
the files "header" and "info" but not for files like "cc", "bcc",
"subject", &c?
is this something that some tools depend on? i don't think
that marshal does since it encodes subjects typed directly
at it.
- erik