ARGF must be called just once for each option that takes an argument.
that means you cannot get the same argument (parameter value) twice,
so you'd better save it if you need it.
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
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 that
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
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
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-only values using lib9p
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
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
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
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
Hello
right, that's just one of the problems erik solved and i was still solving ☺,
the memory usage of upas/fs.
slds.
gabi
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 the
stupid hacks:
echo 1,10p id from|nupas/nedmail $*[2=]
echo 1,10p id flags|nupas/nedmail $*[2=]
- erik
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 ;).
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
* Russ Cox [EMAIL PROTECTED] wrote:
Hi,
Okay, how can I make sure the right toolchain is used, *all*
imports come from within sysroot and *only* code from the
(building) HOST system is executed - *never* from TARGET ?
I would have expected your host system to refuse
to run binaries
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 the
According to arg(2), that's not a good idea.
ARGF must be called just once for each option that takes an
argument.
Who are you going to believe? Me or that lying man page?
See if your code works.
I'm not your code monkey. You mentioned that you
didn't know how to do something; I
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
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 remove the
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 do get
(are there small mboxes anymore? ;)
du -a /mail/box/quanstro/mbox
4 /mail/box/quanstro/mbox/1212376173.00
2 /mail/box/quanstro/mbox/1212378184.00
4 /mail/box/quanstro/mbox/1213282217.00
4 /mail/box/quanstro/mbox/1193334801.00
2
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
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
Thoughts:
+ Running Plan 9 on qemu is slow (when doing disk access) (the
ethernal DMA wiwi bla bla bla)
+ qcow2 is quality challenged, but I think that the standard plan9.img
ain't qcow2
+kqemu has worked for me very well... but I have not benchmarked it.
+ Unpacking 100 MiB sounds like a lot of
Also... Renice if you can.
On 6/12/08, Lorenzo Fernando Bivens de la Fuente
[EMAIL PROTECTED] wrote:
Thoughts:
+ Running Plan 9 on qemu is slow (when doing disk access) (the
ethernal DMA wiwi bla bla bla)
+ qcow2 is quality challenged, but I think that the standard plan9.img
ain't qcow2
I've tried with both qcow2 and raw; raw takes longer to get to a crash,
but still reliably crashes. Strangely, connecting to qemu with gdb
before Plan 9 starts reduces the crash rate a lot, but it might just be
because the world is noticeably slower...
--vs
27 matches
Mail list logo
