I assume that there's a bug in your verbosity code that causes it not to
print out the UID when the list is created for the first time (at "msg =
tail = cur;").
What this looks to me is that a data file for a new mailbox, .mix47028bdd
(created 2007-Oct-02 11:20:13), got mixed in with the older
Mark,
I found the immediate preceding file and removed it but still got the
error. So I added some verbosity to mixrbld and reran it with this output:
/esnet/setup/island.setup/sysfiles/mixrbld .
./.mix470175e2
UID: 2
UID: 3
UID: 4
UID: 5
UID: 6
UID: 7
UID: 8
UID: 9
UID: 10
UID: 11
UID: 12
UID
I think that I understand what is going on. You have two data files that
start with UID 1, so the duplication is inter-file instead of intra-file.
mixdfix only remedies the intra-file case.
Look in that directory. The other file is almost certainly the file that
immediately preceeds .mix4702
Mark,
I applied the patch and as you indicated got this error:
/usr/local/sbin/mixrbld SAVE
Data file SAVE/.mix47028bdd duplicate UID @ 0: 1
So I ran mixdfix and got this message:
/usr/local/sbin/mixdfix SAVE/.mix47028bdd
SAVE/.mix47028bdd: no repair needed
This was after I copied over .mixst
The following patch will fix the core dump. At line 177 of mixrbld.c,
change:
printf ("Data file %s duplicate UID @ %ld: %ls\n",file,pos,cur->uid);
to:
printf ("Data file %s duplicate UID @ %ld: %ld\n",file,pos,cur->uid);
^
Apparently I remember more than I thought (isn't Google wonderful)
gdb mixrbld core.5514
(gdb) bt
#0 0x0040d228 in wcslen () from /lib/tls/libc.so.6
#1 0x0040e284 in wcsrtombs () from /lib/tls/libc.so.6
#2 0x003db8ec in vfprintf () from /lib/tls/libc.so.6
#3 0x003e08e0 in printf () from /lib/
I have some .mix data files and no .mixindex, .mixmeta or .mixstatus
files through a file system manipulation error. I figured I could just
run mixrbld to take the data files and rebuild the other files. To my
horror mixrbld core dumps. I have a core file which compresses to 12K
which I can sen
