Dave Eckhardt <[EMAIL PROTECTED]> writes
| Instead my guess would be something more like: if you're
| rebuilding the quota database you can do so by N/M
| readdir()'s instead of N/M readdir()'s plus N stat()'s,
| which is probably a huge reduction in disk seeks, which
| would be attractive since
> Do you think it might make it easier to change upas/fs to
> not keep the whole mailbox in memory?
i sketched out a design for an imap upas/fs last night.
it is imap in the sense of intended to be used with an imap server
but really that just breaks a handful of the current assumptions.
the new
> (the S=2872 is the file size. i'm not sure why stat is so
> expensive on their machine.)
I suspect it's *not* because of this: AFS directories
are (essentially) whole-file transferred to clients
who interpret them locally, but each stat() requires an
RPC to the server.
Instead my guess would b
uriel,
my limited time is starting to cause major headaches.
i've been working with john cummings on getting upas
ready-for-primetime within plan9port. upas/fs has been
stable for a long time, but not integrated.
perhaps this is silly to worry about, but i'd rather not
have a version in contrib i
> [EMAIL PROTECTED] writes
> | > i added mdir support to upas/fs for p9p. it should work
> | > on mh directories, too.
> | Do you think it might make it easier to change upas/fs to
> | not keep the whole mailbox in memory?
>
> yes, i do. but i didn't go that far.
Ah, that is great news! That limit
[EMAIL PROTECTED] writes
|
| > i added mdir support to upas/fs for p9p. it should work
| > on mh directories, too.
| Do you think it might make it easier to change upas/fs to
| not keep the whole mailbox in memory?
yes, i do. but i didn't go that far.
|
| > this isn't integrated yet, but has
> i added mdir support to upas/fs for p9p. it should work
> on mh directories, too.
Do you think it might make it easier to change upas/fs to
not keep the whole mailbox in memory?
> this isn't integrated yet, but has worked pretty well for me.
What is missing for it to be integrated into the distr
i added mdir support to upas/fs for p9p. it should work
on mh directories, too.
this isn't integrated yet, but has worked pretty well for me.
set me a note if you'd like me to forward the code.
- erik
erik quanstrom <[EMAIL PROTECTED]> writes
| Dan Cross <[EMAIL PROTECTED]> writes
|
| |
| | O
i'm not sure what you have available in your environment, but you
could get around the slow imap connection by running upas/fs,
which can be mounted as a normal fs on linux-2.6.n, n>=13.
i don't use mh, but your description of an mh directory sounds
compatable with the upas/fs layout.
i've been
the standard for the top level is $home/.maildir or $home/Maildir (cyrus).
you can get away with only working with $MAILDIR/new if you don't
have a need for maildir-style folders (which start with a "." and get utf-7-
encoded).
there is disagreement about the format of the unique.file.name. the cy
> Maildir uses the structure folder/{tmp,cur,new}/unique.file.name.
> The files are required to be uniquely named, and there is a convention for
> the intermediate directories. djb has a brief but detailed specification
> under cr.yp.to somewhere, if you want to google for it.
http://cr.yp.to/pro
| MH uses monotonically-increasing small positive integers to number
| messages within a folder. Maildir, as I recall, uses large
| pseudo-random numbers, or what appear to be pseudo-random numbers.
Maildir uses the structure folder/{tmp,cur,new}/unique.file.name.
The files are required to be uni
MH uses monotonically-increasing small positive integers to number
messages within a folder. Maildir, as I recall, uses large
pseudo-random numbers, or what appear to be pseudo-random numbers.
--- Begin Message ---
> On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote:
> > Eventually I might
> On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote:
> > Eventually I might replace the mh programs with code from
> > Plan 9 (still leaving the mh disk layout) but I don't expect to
> > do that any time soon.
>
> Personally, I'd rather that wasn't the case. I'd rather see a version of
> t
On Thu, Jan 19, 2006 at 11:24:36AM -0500, Russ Cox wrote:
> Eventually I might replace the mh programs with code from
> Plan 9 (still leaving the mh disk layout) but I don't expect to
> do that any time soon.
Personally, I'd rather that wasn't the case. I'd rather see a version of
the MH utilitie
> Hey Russ,
> I'd love to try out your script - problem is nmh doesn't seem to like
> modern-ish utilities (gcc 4 et al). Would you know of any other
> utility which would have the same functionality?
I would suggest trying to find an earlier gcc or prebuilt binaries.
Eventually I might replace
Hey Russ,
I'd love to try out your script - problem is nmh doesn't seem to like
modern-ish utilities (gcc 4 et al). Would you know of any other
utility which would have the same functionality?
Mail script should be attached. This time for sure.
Russ
#!/usr/local/plan9/bin/rc
. 9.rc
. $PLAN9/lib/acme.rc
mh=/usr/bin/mh # directory with mh binaries
fn event {
# $1 - c1 origin of event
# $2 - c2 type of action
# $3 - q0 beginning of selection
# $4 - q1
oops, sorry for the noise, didn't mean to send this to the list.
> Russ,
> This is great! I am very eager to try this out.
> However I didn't get the Mail script you attached. It just
> came through as an empty file. Would you mind sending that
> again?
>
> tim
>
>
> > I am sending this from i
Russ,
This is great! I am very eager to try this out.
However I didn't get the Mail script you attached. It just
came through as an empty file. Would you mind sending that
again?
tim
> I am sending this from inside acme Mail on Linux.
> Or at least the program is called Mail.
> It's not actually
I am sending this from inside acme Mail on Linux.
Or at least the program is called Mail.
It's not actually the Mail from Plan 9.
I am running mh and have 'customized' it to print
something close to sensible output. Mail itself
is a shell script. The interactive delay is a little
annoying someti
21 matches
Mail list logo
