Hello

I've a 9p server implemented using lib9p which serves decoded files, for example, i have a base64 encoded file i want to read, but i want to decode it at the same time the client reads. Then i need to save two offsets, the one sent to the client corresponds to the decoded data, and i need other which correspond to the original data. (base64 is an example, rfc2047 codification is the main issue)

If i save the offset adjustment in f->aux or simmilar, i can calculate the real file offset on the next T-reads, but that will only work if one client reads it at one time.

could that value be saved for each session?

i would love to hear from other's experiences,

thanks,

gabi

No it won't. Even if just one client is reading, that client might seek.

You could assume that most reads will pick up where the
last one left off, and use f->aux to point at a single hint
that you can check. Maybe you're willing to do more work
if you do get a seek. Otherwise you'll need to build a more
complex data structure to help you map between the two.

Also, if f is a Fid* (not a File*), then you get a different f for each
different Topen of the file (and thus also for each client), so the
hint-per-Fid usually works pretty well in practice for this kind
of thing.

Russ

i've been spending a little time with upas/fs. i don't think that in
general one can get by parsing part of an email, unless that part
happens to be top-level headers. there are more transforms than
you've mentioned. apple mail loves to put nulls in html email, for
example.

traditional mbox format is problematic, too.

if you wish to control memory usage (which is a serious problem for
upas/fs), i think the way to go is a cache with reference counting.

the stuff i have isn't ready for prime time, but it's coming along
nicely.

the date is the date it was delivered.
it's a receiver-side postmark.
but you knew that. what's your question?

russ

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

On 2008-Jun-11, at 19:31 , erik quanstrom wrote:

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

hello

at the moment i'm playing only with mbox not imap or pop, i have a version with cache per message that 'works', upas/nedmail and acme/mail are able to read messages 'nicely', but attachments are not decoded.

also file lengths is going to be a problem if i'm going to decode files within the fs.

i've put what i have in /n/sources/contrib/gabidiaz/wip/mboxfs

about the From line, qmail man page about mbox format says it is composed of From space sender@... space current date, and it is generated by the delivery agent, but moving one message from a box to another doesn't use the delivery agent :-?

thanks,

gabi

i have a couple of reservations about mbox format. first, a majority
of users that i need to support have inboxes >10mb and some
have mailboxes >100mb. thus deleting an older message will require
rewriting the whole file, and if it's not the last message, will take
up quite a bit of storage, even on venti.

second, it's very difficult to cache. for example, suppose i have two
instances of my mail fs interpreting the same mbox at the same time.
suppose that i delete the 5th out of 500 messages with the first. the
second will then have to reread the entire mbox to get its pointers
right. even if i write an index with the first, the entire index
needs to be reread.

third, since large messages tend to be really stinking huge, it is not
efficient to read entire messages to deduce the mime structure. (ned
reads the mime structure of each doc on startup.) that last mime part
may be tens of mb into the

Funny, I've done the same in a different way.
see mail2fs in contrib/nemo.
Also, I have some proposal, skip to the end of the mail and let me know
what you think :)

In any case, I'd love to see/try your version of upas/fs et al.

Instead of adapting upas/fs, I use a mail2fs program that uses
upas to convert mail into an "unpacked" form. Each mail is a directory.
A "text" file contains the message text right as you would see it in a mail
reader (including relative paths for attachments). Each attach is decoded
and kept in the mail's directory ready to be copied, printed, etc.; if possible,
using the same file name reported by the attachment.

I use the very same approach for sending mail. A directory /mail/box/nemo/out
is spooled to send whichever file is placed on it as a mail. The format for the
outgoing messages is again similar to what you'd type in a mail writer.

The whole point is that now you editor (plus couple of scripts) becomes a mail
reader/writer without understanding anything about mail.

hello

great news, i just used mbox to avoid reworking the whole thing at the same time, but you already done it. I was already aware of the mbox-pain.

i'll be pleased to help on this, test, bug report, try it on a public server or whatever it's needed to finish this up.

About the date in the From line, it is supposed that the From line is written when the mail is delivered, i mean, the action of saving the email on a file. If you write it in mbox, then no new From will be written when you move that message. I'm not sure i understand the problem here.

thanks

gabi