klarich@d.cs.okstate.edu (KLARICH TERRY JAME) (07/18/90)
Currently, I have mmdf installed on an ultrix machine which I manage. I would like to provide a variety of mail interfaces for the users. After looking at mush, I thaught I would try and get it up and running. I have two questions I can't seem to find the answers for. First, is there any way to keep mush from messing up the "._.mail" file used by mmdf? Second, could some one let me know what is actually required to get mush to talk to "/usr/mmdf/submit"? Terry Klarich <klarich@d.cs.okstate.edu> or <terry@unx.ucc.okstate.edu>
mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) (07/18/90)
klarich@d.cs.okstate.edu (KLARICH TERRY JAME) writes: >Currently, I have mmdf installed on an ultrix machine which I manage. I would >like to provide a variety of mail interfaces for the users. After looking at >mush, I thaught I would try and get it up and running. I have two questions I >can't seem to find the answers for. First, is there any way to keep mush >from messing up the "._.mail" file used by mmdf? Second, could some one >let me know what is actually required to get mush to talk to >"/usr/mmdf/submit"? I'm not familiar with the "._.mail" file? What is it used for? Is it a lockfile? What sort of locking does your MMDF installation use? Regarding your second question, you should be ok if you just change the "/usr/mmdf/bin/submit" in config.h-dist to "/usr/mmdf/submit" in config.h. What are the symptoms of mush's failure to communicate with submit? -- Marc Rouleau
ronald@robobar.co.uk (Ronald S H Khoo) (07/19/90)
In article <1990Jul18.143855.11452@murdoch.acc.Virginia.EDU> mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) writes: > I'm not familiar with the "._.mail" file? What is it used for? It's a binary index file into the mail folder. For those of us with multi-megabyte folders and lousy PC disc subsystems, it's a godsend. You're making me miss msg/mmdf :-( I did ask about msg compatible binary index files for mush at one stage, but the mush development team don't run mmdf, so one can hardly expect them to provide it ! There has been some talk about binary index files for mush, and it would be nice if they were the same as msg/mmdf's, but I don't see how that's going to happen. Maybe we need to wait for indexes to happen first, then hack it to work with ._.mail. I dunno. Maybe we need a volunteer who's familiar with mmdf (I'm not) to help -- perhaps the guy who did the original mmdf support ? > Regarding your second question, you should be ok if you just change > the "/usr/mmdf/bin/submit" in config.h-dist to "/usr/mmdf/submit" That sounds about right. I think /usr/mmdf/submit ought to be the default anyway, seeing as that's the mmdf installation default as well. -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) (07/19/90)
ronald@robobar.co.uk (Ronald S H Khoo) writes: >mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) writes: >> I'm not familiar with the "._.mail" file? What is it used for? > >It's a binary index file into the mail folder. Oh, so mush isn't trashing the file, it's just changing the system mailbox so that ._.mail is no longer relevant. It's hard to see how you could use both mush AND msg. As you point out below, mush would have to use msg's index scheme. (We don't run msg/send here, which is why I didn't know what the ._.mail file was.) >I did ask about msg compatible binary index files for mush at one stage, >but the mush development team don't run mmdf, so one can hardly expect them >to provide it ! There has been some talk about binary index files for >mush, and it would be nice if they were the same as msg/mmdf's, but I don't >see how that's going to happen. Maybe we need to wait for indexes to happen >first, then hack it to work with ._.mail. I dunno. Maybe we need a >volunteer who's familiar with mmdf (I'm not) to help -- perhaps the guy >who did the original mmdf support ? That's me, and I'm not volunteering. :-) >> Regarding your second question, you should be ok if you just change >> the "/usr/mmdf/bin/submit" in config.h-dist to "/usr/mmdf/submit" > >That sounds about right. I think /usr/mmdf/submit ought to be the default >anyway, seeing as that's the mmdf installation default as well. If that's true for all MMDFs (not just spinoffs like that of SCO Unix), then I guess you might be right. I just set it to the correct value for our site. Since I didn't install MMDF here originally, I don't know what the default for our version was at the time, and our makefiles have been hacked severely since then. -- Marc Rouleau
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (07/20/90)
In article <1990Jul19.065835.11243@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: } In article <1990Jul18.143855.11452@murdoch.acc.Virginia.EDU> mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) writes: } } > I'm not familiar with the "._.mail" file? What is it used for? } } It's a binary index file into the mail folder. For those of us with } multi-megabyte folders and lousy PC disc subsystems, it's a godsend. } You're making me miss msg/mmdf :-( If somebody sends Dan or I a detailed description of the format, we'll consider supporting it. -- Bart Schaefer schaefer@cse.ogi.edu
ronald@robobar.co.uk (Ronald S H Khoo) (07/20/90)
[ Bart, a short description of ._.mail format is below. Don't hit 'n' yet! ] In article <1990Jul19.155151.29977@murdoch.acc.Virginia.EDU> mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) writes: > Oh, so mush isn't trashing the file, it's just changing the system > mailbox so that ._.mail is no longer relevant. It's hard to see > how you could use both mush AND msg. Hack fix: modify mush to throw away the ._.mail file when it re-writes the mailbox. msg will recreate it. After all, that's what msg tells you to do anyway, so you might as well do it automagically. >>perhaps the guy >>who did the original mmdf support ? >That's me, and I'm not volunteering. :-) Oooops! Sorry ... :-) [ submit in toplevel of /usr/mmdf ] >If that's true for all MMDFs (not just spinoffs like that of SCO Unix), I dunno about ALL MMDF's, but that's the default in the current MMDF source distribution. I have a box of SCO Unix in the corridor delivered this morning to play with, so guess what I'm going to do with their MMDF ? :-) > -- Marc Rouleau Hm. msg is 5000 lines of code, in files called msg[0-6].c :-( However, the structure of the ._.mail file is found in msg.h. It consists of 1 struct status followed by n struct message records. Obviously there may be more than n messages in .mail if any mail has arrived since the last time msg was fired up. Quoting from msg.h, probably in violation of some UDel license :-) -- note that datestr simply contains stuff like "20 Jul 90" -- Bart, I'll look harder at it if you think it's worth it, and if you think that this will fit into mush at all. /* -- begin extract from /usr/local/src/mmdf.upd43/src/uip/msg/msg.h */ #define SIZEDATE 9 #define SIZEFROM 30 /* ALSO change hdrfmt */ #define SIZESUBJ 40 /* */ #define SIZETO 30 /* Status structure, also exists at the front of a binary index file. */ struct status { int ms_ident; /* "Magic Number" */ long ms_time; /* Last time file was processed */ unsigned ms_nmsgs; /* Number of messages processed */ unsigned ms_curmsg; /* "Current" message */ long ms_eofpos; /* Msg file eof position */ unsigned ms_markno; /* Marked message no */ int ms_xxx1; /* Place holder - not used */ int ms_xxx2; /* Place holder - not used */ long ms_xxx3; /* Place holder - not used */ }; struct message { long start; /* Offset into file */ long len; /* Length of message */ int flags; /* FLAGS word */ long date; char datestr[SIZEDATE]; char from[SIZEFROM]; char to[SIZETO]; char subject[SIZESUBJ]; }; -- Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343 Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
schaefer@ogicse.ogc.edu (Barton E. Schaefer) (07/21/90)
In article <1990Jul20.090225.5008@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: } [ Bart, a short description of ._.mail format is below. Don't hit 'n' yet! ] I deliberately get all this stuff both via news and via the mush-users list so I won't accidentally lose anything important. } the structure of the ._.mail file is found in msg.h. It consists of 1 } struct status followed by n struct message records. Seems doubtful that mush would be able to deal with this properly without considerably more information on how each of the fields is generated, especially the "magic number" in struct status. Mush also would have to support those data structures exactly in order to write out the correct binary form. If it had been an ascii format, or even a binary that wasn't a dump of an array of structures, it might have been possible. } Bart, I'll look harder at it if you think it's worth it, } and if you think that this will fit into mush at all. I think the best idea is just to have mush remove the "._.mail" fail on update when MMDF is defined. Is the index file name always the folder name with "._." prepended? -- Bart Schaefer schaefer@cse.ogi.edu
dpk@Morgan.COM (Doug Kingston) (07/21/90)
Some quick history on ._ files and the msg mail reader. msg came to BRL and other MMDF sites as a sample and full featured mail reader along with the core of the MMDF distribution. It is not considered a real part of MMDF which is really only an MTA (mail transfer agent). These days we also provide a copy of UCBmail and the /bin/mail replacement we have always had. At BRL, MMDF met large mailboxes, principally those of myself and Mike Muuss. We got tired of it taking minutes to start up msg on our mailboxes (which often contained 100 new messages a day back in 1983), so we added the "binary box" that was maintained in parallel with mailbox (we had our mail delivered to $HOME/mailbox). The binary box began with "._". It has all the information that a mail reader needs to sort and display messages. In fact, it only reads the message text once when a new message is added to the mailbox. This makes the startup for msg faster than any other mail reader. If there are no new messages, it takes four system calls (open, stat, malloc, read) and msg is ready to go. I would love to see this facility in MUSH. In retrospect, we should have switched to network by ordering in the file, and perhaps fixed lenght ascii readers a long time ago, but now is as good a time as any. Startup would be an order of magnitude faster on large mailboxes. Basicly you want all the incore information written out in a fixed format for retrival. In more recent msg changes, the binary box reading code has gotten rather careful about checksuming the binary box and making sure the last message is where we expect it as a safety check. I would be willing to work with folks on this if there is interest from Bart & Co. -Doug-
david@twg.com (David S. Herron) (07/22/90)
In article <1990Jul17.204302.18027@d.cs.okstate.edu> klarich@d.cs.okstate.edu (KLARICH TERRY JAME) writes: >Currently, I have mmdf installed on an ultrix machine which I manage. I would > like to provide a variety of mail interfaces for the users. After looking at >mush, I thaught I would try and get it up and running. I have two questions I >can't seem to find the answers for. ... > First, is there any way to keep mush >from messing up the "._.mail" file used by mmdf? That '._' file is used by `msg' (only) so that msg can know where all the messages in the mailbox are. If you use some other mail reader which doesn't maintain that file, be it vi(1) or elm or the ucbmail provided with MMDF, it will modify the file. Among the attributes kept in the file is time&date stamps and size. The way to keep mush from `messing' that file up is to not use mush. Given a choice between those two I prefer msg, but my real choice in user agents is xmh... :-) > Second, could some one >let me know what is actually required to get mush to talk to >"/usr/mmdf/submit"? Out of the box mush talks to submit by the way of the sendmail emulator included with MMDF. One problem, which I haven't tracked down yet, is that (at least with the mush installed at ms.uky.edu) the return-address-for-errors ends up pointing at the postmaster. Not good.. User agents are supposed to use one of two sets of routines for talking to submit. They are the ml_*() and mm_*() routines, and are located in libmmdf.a and compiled from source under lib/mmdf. In the MMDF documentation, in section 3, there are manual pages for both of these modules. If that isn't enough then there are a few small programs in the source tree which you can use as examples. For instance, the sendmail emulator mentioned above, the v6mail program might be a better example. >Terry Klarich <klarich@d.cs.okstate.edu> or <terry@unx.ucc.okstate.edu> -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
mer6g@virginia.acc.Virginia.EDU (Marc Rouleau) (07/22/90)
david@twg.com (David S. Herron) writes: >klarich@d.cs.okstate.edu (KLARICH TERRY JAME) writes: >> Second, could some one >>let me know what is actually required to get mush to talk to >>"/usr/mmdf/submit"? > >Out of the box mush talks to submit by the way of the sendmail >emulator included with MMDF. No. Out of the box mush talks to submit by way of the established command line interface. The default is "submit -mlnr" if memory serves. I believe this has been so for at least two years. > One problem, which I haven't tracked >down yet, is that (at least with the mush installed at ms.uky.edu) >the return-address-for-errors ends up pointing at the postmaster. >Not good.. I think the fake sendmail interface to submit is a lamentable hack, especially when mush, elm, and mh already support submit's perfectly good command line interface. >User agents are supposed to use one of two sets of routines for >talking to submit. They are the ml_*() and mm_*() routines, and >are located in libmmdf.a and compiled from source under lib/mmdf. Ugh. I think the command-line interface is much cleaner. One of the many reasons is that lots of MMDF sites lack source. It would be foolish for developers of portable user agents to require that installers of their packages have copies of libmmdf.a handy. -- Marc Rouleau
david@twg.com (David S. Herron) (07/23/90)
In article <1990Jul20.090225.5008@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
</* -- begin extract from /usr/local/src/mmdf.upd43/src/uip/msg/msg.h */
<#define SIZEDATE 9
<#define SIZEFROM 30 /* ALSO change hdrfmt */
<#define SIZESUBJ 40 /* */
<#define SIZETO 30
<
</* Status structure, also exists at the front of a binary index file. */
<struct status {
< int ms_ident; /* "Magic Number" */
< long ms_time; /* Last time file was processed */
< unsigned ms_nmsgs; /* Number of messages processed */
< unsigned ms_curmsg; /* "Current" message */
< long ms_eofpos; /* Msg file eof position */
^^^^
< unsigned ms_markno; /* Marked message no */
< int ms_xxx1; /* Place holder - not used */
< int ms_xxx2; /* Place holder - not used */
< long ms_xxx3; /* Place holder - not used */
<};
<
<struct message {
< long start; /* Offset into file */
^^^^
< long len; /* Length of message */
< int flags; /* FLAGS word */
< long date;
< char datestr[SIZEDATE];
< char from[SIZEFROM];
< char to[SIZETO];
< char subject[SIZESUBJ];
<};
At least the two lines marked will at some point change to off_t and
be byte swapped using ntoh*() routines. For portability of binary
boxes across dissimilar systems.
Bart&Bob, if'n you get serious 'bout putting binary box mode into
mush I can arrange to give you source :-)..
<--
<Eunet: Ronald.Khoo@robobar.Co.Uk Phone: +44 81 991 1142 Fax: +44 81 998 8343
<Paper: Robobar Ltd. 22 Wadsworth Road, Perivale, Middx., UB6 7JD ENGLAND.
--
<- David Herron, an MMDF weenie, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!jackm@QA1.PICA.ARMY.MIL (Jack Moskowitz) (07/23/90)
The MMDF binary box prefix is "._" not "._.". For example: ._mailbox. > > I think the best idea is just to have mush remove the "._.mail" fail on > update when MMDF is defined. Is the index file name always the folder > name with "._." prepended? > -- > Bart Schaefer schaefer@cse.ogi.edu
pcg@cs.aber.ac.uk (Piercarlo Grandi) (07/26/90)
In article <9007211604.AA17220@Morgan.COM> dpk@Morgan.COM (Doug Kingston) writes:
I would love to see this facility in MUSH. In retrospect, we should
have switched to network by ordering in the file, and perhaps fixed
lenght ascii readers a long time ago, but now is as good a time as
any. Startup would be an order of magnitude faster on large mailboxes.
Basicly you want all the incore information written out in a fixed
format for retrival.
MUSH unfortunately currently has a fairly slow way of doing things. I
have just got these numbers:
folder: 1,094,949 bytes with 348 messages
MUSH 7.1 PL2: grows to 99 4KB pages, display 348 msgs in 15 screens
real user sys
read 16.2 5.2 4.0
browse 34.4 12.1 8.4
sort -i -s -d 73.5 15.6 17.9 (sorting by subject and date)
sort -l 17.6 5.9 4.3 (sorting by number of lines)
ELM 2.3 PL5: grows to 137 4KB pages, displays 348 msgs in 21 screens
read 15.9 7.9 4.1
browse 20.1 9.2 6.9
sort 17.5 9.1 4.5
Notes: on SysV/386 (ESIX) on a 20 Mhz cached 386, approx. 4
MIPS; programs fully memory resident, no paging; system
otherwise inactive; times in seconds; the folder was contiguous
on disc and optimally laid out; timings have been repeated and
are consistent; 'read' is just opening the folder and exiting;
'browse' is opening the folder and paging down all the
screenfuls; 'sort' is opening the folder and sorting the
headers; to make real time measures meaningful all the needed
commands have been typed ahead while the editor was reading the
folder. All times are therefore the 'best' times.
The colossal difference in favour of ELM for one of the sorts and for
browsing is because ELM keeps in memory the headers of all messages, in
a binary form, when the folder is opened (see the higher startup time),
while MUSH refetches and reparses most header lines on every access to
the message. Were it not for that, MUSH would be as fast as ELM, as the
sort by lines (the line count is kept in memory...) seems to indicate.
If this problem were fixed one of my two main objections to MUSH would
be removed (the other one is that I'd like to *optionally* ask that the
folder be copied to a temp file and back only when I ask for it or quit,
not immediately when I start browsing it).
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukdavid@twg.com (David S. Herron) (07/29/90)
In article <9007211604.AA17220@Morgan.COM> dpk@Morgan.COM (Doug Kingston) writes: >I would be willing to work with folks on this if there is interest >from Bart & Co. > >-Doug- Go for it.. Unfortunately I don't have time to help out ... one of the things on my list for msg is network-byte-ordering for the binary box. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!