We plan to copy our users email (about 350 gig for about 2000 users) to our
new server which we plan to setup with mix format mailboxes. Our testing
looks good but it looks like mailutil does not follow the file size setup
in mix.c which the server itself follows fine. We will have a few users
with the first email data file (the one from their copied email) 400 or 500
meg. Is there a way to get mailutil to make a certain size file? Are the
large files we may get not an issue?

Thanks,

Andy

On Wed, 11 Apr 2007, Outsider wrote:
> We plan to copy our users email (about 350 gig for about 2000 users) to our
> new server which we plan to setup with mix format mailboxes. Our testing
> looks good but it looks like mailutil does not follow the file size setup
> in mix.c which the server itself follows fine. We will have a few users
> with the first email data file (the one from their copied email) 400 or 500
> meg. Is there a way to get mailutil to make a certain size file? Are the
> large files we may get not an issue?

This is known behavior of mailutil. The large data files are not an issue
other than being large data files.

This happens because mailutil does an aggregate copy which is, by
defintion, atomic. mailutil also does not preserve the UID regime of the
source file. What this all means is that mailutil is less than fully
satisfactory as a tool to convert a mailbox to mix format, although it can
be used for that purpose.

The remedy is to use mixcvt, a tool specifically written to convert a
mailbox to mix format. Although mixcvt uses the c-client library to read
a mailbox, it works outside it to create the new mix mailbox and thus can
violate c-client's aggregate-copy and new UID rules (which are normally
desirable rules, but get in the way when you want to convert).
ftp://ftp.cac.washington.edu/mail/mixcvt.tar.Z

Another tool which you may find useful is mixrbld. This tool will rebuild
the mix index file from the data files, assuming that the data files
themselves are intact (a future tool will allow repair of corrupt data
files).
ftp://ftp.cac.washington.edu/mail/mixrbld.tar.Z

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Mark Crispin <MRC@CAC.Washington.EDU> wrote in
news:alpine.WNT.0.98.0704111616420.3800@Tomobiki-Cho.CAC.Washington.EDU:

> On Wed, 11 Apr 2007, Outsider wrote:
>> We plan to copy our users email (about 350 gig for about 2000 users)
>> to our new server which we plan to setup with mix format mailboxes.
>> Our testing looks good but it looks like mailutil does not follow the
>> file size setup in mix.c which the server itself follows fine. We
>> will have a few users with the first email data file (the one from
>> their copied email) 400 or 500 meg. Is there a way to get mailutil
>> to make a certain size file? Are the large files we may get not an
>> issue?
>
> This is known behavior of mailutil. The large data files are not an
> issue other than being large data files.
>
> This happens because mailutil does an aggregate copy which is, by
> defintion, atomic. mailutil also does not preserve the UID regime of
> the source file. What this all means is that mailutil is less than
> fully satisfactory as a tool to convert a mailbox to mix format,
> although it can be used for that purpose.
>
> The remedy is to use mixcvt, a tool specifically written to convert a
> mailbox to mix format. Although mixcvt uses the c-client library to
> read a mailbox, it works outside it to create the new mix mailbox and
> thus can violate c-client's aggregate-copy and new UID rules (which
> are normally desirable rules, but get in the way when you want to
> convert).
> ftp://ftp.cac.washington.edu/mail/mixcvt.tar.Z
>
> Another tool which you may find useful is mixrbld. This tool will
> rebuild the mix index file from the data files, assuming that the data
> files themselves are intact (a future tool will allow repair of
> corrupt data files).
> ftp://ftp.cac.washington.edu/mail/mixrbld.tar.Z
>
> -- Mark --
>
> http://staff.washington.edu/mrc
> Science does not emerge from voting, party politics, or public debate.
> Si vis pacem, para bellum.
>


Thanks Mark. We will check the other tools out. I did like how fast
mailutil did its work and I am not really sure the large files bother me
a lot but they upset my sense of symetry a little. We will see if the
other tools are a better fit for us but assume mailutil is a fine fall-
back. Thanks for the quick response (and the new format).

Andy

On Wed, 11 Apr 2007, Outsider wrote:
> Thanks Mark. We will check the other tools out. I did like how fast
> mailutil did its work and I am not really sure the large files bother me
> a lot but they upset my sense of symetry a little. We will see if the
> other tools are a better fit for us but assume mailutil is a fine fall-
> back. Thanks for the quick response (and the new format).

You're welcome. For what it's worth mixcvt should be faster than
mailutil. mailutil is a very general program, whereas mixcvt is a
specialist.

The separate mixcvt/mixrbld programs are not the final word; maybe this
functionality will ultimately incorporated into mailutil or into some
other tool specifically for mix. This is all still a work-in-progress.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.