Re: [9fans] upas/fs still modifying gmail inbox after window closed
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 inbox continue to get marked as read >> shortly after they arrive. my assumption is that upas/fs is still >> accessing the mailbox. how can i prove (or disprove) this, and stop >> it from happening? > > echo close mbox > /mail/fs/ctl > > i don't know if nupas handles this correctly or not. but i > seem to recall that it does. it's a matter of issuing the right > imap command when you're fetching the message body for > internal use, rather than for viewing. should this work even when my namespace doesn't reflect the gmail mount? the rio window where i started upas/fs died and disappeared (note: without my intervention) sometime last night. i can't find any trace of the gmail messages on my system. i sent the command above, but messages in my gmail inbox are still getting marked as read a few seconds after they arrive. in the future i'll try nupas. thanks, -sl
Re: [9fans] upas/fs still modifying gmail inbox after window closed
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. my assumption is that upas/fs is still > accessing the mailbox. how can i prove (or disprove) this, and stop > it from happening? echo close mbox > /mail/fs/ctl i don't know if nupas handles this correctly or not. but i seem to recall that it does. it's a matter of issuing the right imap command when you're fetching the message body for internal use, rather than for viewing. - erik
[9fans] upas/fs still modifying gmail inbox after window closed
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 i prove (or disprove) this, and stop it from happening? -sl
Re: [9fans] upas/fs
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 UNIX mail implementation. The \n^From separator line got generated at initial delivery time, and the mail client used that as the display time in the message summaries (e.g. Date: not spoken here). Therefore it makes sense to preserve the initial separator line with it's date intact to ensure consistency for display purposes. Think of it as the UNIX ctime of the message. --lyndon
Re: [9fans] upas/fs
>> 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 receiver-side postmark. > but you knew that. what's your question? 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? - erik
Re: [9fans] upas/fs
> 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 postmark. but you knew that. what's your question? russ
[9fans] upas/fs rfc 2047 encoding
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
