> In any way, I'd still be converting my mail to the new format, because
> of the convenience of having everything unpacked and ready to read,
> and because of the space it's likely to be saving in venti.
It is unavoidable that once you have a permanent filesystem for mail
you'll also need the abi
> Why don't we reach an agreement and start using the very
> same format. I suggest keeping my mbox format but adapting upas/fs to
> understand it, which is a good idea. But I'm open to suggestions.
... and use base64 encoding of attachment names so they can be
displayed correctly (by a clever fu
nstro mbox" and get
> the
> paths/lines for messages relevant; etc.
why not:
bind /bin/nupas /bin/upas
grep -l nemo /mail/fs/mbox/*/from |
awk -F/ '{print $(NF-1) "p id subject" }' |
upas/nedmail -n>[2=]
22 Re
Sorry. I mean, "*Yes*, but ...".
I mean, you are right (unless you remove the raw files for non-spam mails
after some time; which I do not).
> > in addition, doesn't storing mail your way increase the storage
> requirements?
>
> No. Same file sent multiple times with different mails (which I
> > But the nice thing is that you can edit text, copy attachments in/out,
> > remove them, etc. etc.
> this is already possible with upas/fs, isn't it? also, i get the benefit
> of not being tied into message formats. for example, i can use imap.
Nope. If you try to remove an attach you remov
> If, the reply was inlined. Anyone wanting to use the original can go use raw.
> But the nice thing is that you can edit text, copy attachments in/out,
> remove them, etc. etc.
this is already possible with upas/fs, isn't it? also, i get the benefit
of not being tied into message formats. for e
> if you view the date that way, as an integral part
> of the delivered message, it would sure be strange
> if saving the message to a different folder altered
> the delivery date. receiving a message and filing
> a message are two very different things.
>
>> so copying a message
>> really copies
> why not? the "From " line is written when the message is delivered to a
> mb. but it's not part of the message proper.
that may be your mental model, but it's not mine.
to me, the From line is as much part of the message
as the rest of the mail. like i said before, it is a
postmark. it in
This mail with a reply inlined would be
msgdir/
msgdir/text
msgdir/raw
If, the reply was inlined. Anyone wanting to use the original can go use raw.
But the nice thing is that you can edit text, copy attachments in/out,
remove them, etc. etc.
Compatibility in my case is achieved by leaving upas e
hello
hehe, i don't know why it is copied, probably because if you use mbox format
you need the From line as a message delimeter, but if you're using other
format, the From line could be avoided. As we are talking about email, may be
it has a hidden meaning nobody remembers now ;).
greetings,
stupid hacks:
echo 1,10p id from|nupas/nedmail $*>[2=]
echo 1,10p id flags|nupas/nedmail $*>[2=]
- erik
> 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.
/n/sources/contrib/quanstro/src/nupas. cavet emptor.
n
> 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.
why not? the "From " line is written when th
Hello
right, that's just one of the problems erik solved and i was still solving ☺,
the memory usage of upas/fs.
slds.
gabi
It copies *and* parses the attachment, but I admit that you have to
be able to keep at least the single mail in memory while converting it
to the new format.
Should this be a problem, perhaps doing what Russ suggested
(fixing upas/fs to let it handle big files) would be the right thing.
In any wa
Hello
iirc, mail2fs calls upas/fs then copy /mail/fs/box/files to build the new
layout, but if you call upas/fs on a message with a 10mb attachment, upas/fs
will load the whole thing in ram, mail2fs will write it to a file, then upas/fs
will end it s operation.
but the memory usage will be hug
I don't understand.
mail2fs parses attachments. It uses upas/fs, but it parses attachs.
On Thu, Jun 12, 2008 at 12:39 PM, <[EMAIL PROTECTED]> wrote:
> Hello
>
> I used your mail2fs to store my mail archives for a couple of months (and
> still use it ☺), but the main problem, which is parse atta
Hello
I used your mail2fs to store my mail archives for a couple of months (and still
use it ☺), but the main problem, which is parse attachments using upas/fs, is
not solved.
what erik has done is great, i would vote to have it finished soon ☺
slds.
gabi
FTS, http://lsub.org/magic/man2html/1/mails
is the manual page for the mail program I refer to in the previous mail.
> From: [EMAIL PROTECTED]
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Jun 12 12:24:45 CET 2008
> Subject: Re: [9fans] store 9p session-on
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
pas/fs to
understand it, which is a good idea. But I'm open to suggestions.
thanks
> From: [EMAIL PROTECTED]
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Jun 12 12:10:32 CET 2008
> Subject: Re: [9fans] store 9p session-only values using lib9p
>
>
> 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.
i have a couple of reservations about mbox format. first, a majority
of users tha
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
t
> 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
hello
you're right, i will think a bit more about it.
thank you very much,
gabi
> 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.
No it won't. Even if just one client is reading, that client might seek.
You could assume that most reads will pic
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
27 matches
Mail list logo
