ml>> ok, so don't name them like that... FE, by default, will generate a
 ml>> name for them when areas are autoadded... however, it is as bad or
 ml>> worse to look in the config and see G:\JAM\FIDO9\FEF656FA and have to
 ml>> figure out that that is the LINUX-USER echo...

 DE>>> Ok. so is that a message base file for:
 DE>>> alt.bbs.elebbs?
 DE>>> or
 DE>>> alt.bbs.ra?
 DE>>> or
 DE>>> alt.bbs.doors?
 DE>>> or
 DE>>> alt.bbs.lists?
 DE>>> or alt.bbs.allsysop?

 DE>>> Get the idea? :>

 ml>> yeah, i see that you are not using a hierarchy of directories for your
 ml>> message areas...

 ml>>   ie: g:\jam\alt\bbs\elebbs
 ml>>       g:\jam\alt\bbs\ra
 ml>>       g:\jam\alt\bbs\doors
 ml>>       g:\jam\alt\bbs\lists
 ml>>       g:\jam\alt\bbs\allsysop
 ml>>       g:\jam\alt\something\else
 ml>>       g:\jam\comp\bbs\waffle

 ml>> the dots in those names are to indicate directories and directory
 ml>> structures... you don't have to shove 32 areas all into one directory
 ml>> and probably shouldn't put any more than 30 in one area... this is for
 ml>> speed consideration for the OS reading the FAT tables... there is/was
 ml>> a penalty once an area hit 128 (?) files in a directory... this is why
 ml>> *.MSG (SDM) areas and one file per message area get slow...

 DE> thats not the point. Fastecho is not naming them, I am.

understood... this part should have been above my paragraph above... my
point above that paragraph is that you could/should use a heirarchy for
areas with names like that... it only makes sense... yeah, doing the
longfilename thing makes some sense, too, but only in those cases where
folk don't know about directories and have only known a GUI rather than
what's really happening behind all the purdy colors and pictures...

 DE> And I was not aware of any such problems in file access as you
 DE> describe.

its an old DOS limitation... FAT32 may not have the same limit, YMMV, etc...

an additional unspoken point that i was also subtly making is that in case
of an emergency, one can move their message bases to a DOS v3-v6 machine
and be able to retain them without loosing those oh so desirable long
filenames... an excellent point for maintaining a backup of the BBS
installation so that if the current box does experiance catastrophic
meltdown, one can take that old DOS box, connect it to the phone line and
get back online with little loss... sure, some stuff would be lost but
you'd be able to get back online and limp along rather than being shutdown
until such time as the main system could be repaired or replaced... i used
DOS in this paragraph but i'm also speaking of being able to pop back under
DOSEMU on linux if necessary...

 DE> To me the BBS has always seemed fine with everything
 DE> in c:\bbs\ele\msgbase. I suppose I could look into doing it
 DE> like that, but if I was to do it that way, how would I store
 DE> alt.bbs vs alt.bbs.lists? i.e. the file would be
 DE> c:\bbs\ele\msgbase\usenet\alt\bbs for alt.bbs and
 DE> c:\bbs\ele\msgbase\usenet\alt\bbs\lists for alt.bbs.lists. So,
 DE> now comes the interesting point. I'm getting a file and a
 DE> directory of the same name in the same place. Doesn't work
 DE> very well.

sure it does... remember, there are extensions on the message base data
files... your example above would actually result in...

 c:\bbs\ele\msgbase\usenet\alt\bbs.jdt
 c:\bbs\ele\msgbase\usenet\alt\bbs.jdx
 c:\bbs\ele\msgbase\usenet\alt\bbs.jhr
 c:\bbs\ele\msgbase\usenet\alt\bbs.jlr
 c:\bbs\ele\msgbase\usenet\alt\bbs\lists.jdt
 c:\bbs\ele\msgbase\usenet\alt\bbs\lists.jdx
 c:\bbs\ele\msgbase\usenet\alt\bbs\lists.jhr
 c:\bbs\ele\msgbase\usenet\alt\bbs\lists.jlr


 DE> Perhaps I am just not seeing the way you are
 DE> describing it (or trying to) but that is the problem I see
 DE> with your naming schemes so far. If you have overcome this,
 DE> I'm all ears.

OB-)   see? no conflict...

 ml>> as for 8.3 being a restriction... i tend to see it more as teaching
 ml>> me
 ml>> about how to build a hierarchy and to catagorize or pigeonhole where
 ml>> certain items should be placed... it also lets me build a system that
 ml>> can be accessed much faster than one that carries everything in one
 ml>> central location...

 DE> I have always found one central location to be very easy to
 DE> manage.

yup, me too... mine are all currently based off of G:\JAM but i have had
them spread all over C:\JAM, D:\JAM, E:\JAM, F:\JAM, G:\JAM, H:\JAM with
some several hundred areas in subdirectories in each...

 DE> And I admit, names like FE981252 are not the most
 DE> descriptive. But I can live with that. Call me lazy. I don't
 DE> mind those since *I* don't have to remember what they are. I
 DE> do slowly convert them into more meaningful names, but it's a
 DE> low priority item.

hey! i do that too! >  just adjust them in FE and then in
RA... one open in one screen and the other open in another screen... i
could manually update FM (frontdoor's editor) but i generally run a util
that handles that one for me... its been quite a while since i've done
that, though...

 ml>> ok, so why even use HMB at all? why make your tosser have to switch
 ml>> gears during its operation? once you get up to speed, maintain it!
 ml>> there's enough other things out there that will cause a loss of speed
 ml>> during the operations... ie: opening and closing the bases to put
 ml>> messages in them... this is why some folk like to sort their mail PKTs
 ml>> before they toss them... that way, they can toss all of alt.bbs.ra in
 ml>> one go and then move on to the next base... i like sorting the areas
 ml>> together but i prefer to keep them in the order in which they arrive
 ml>> on system rather than in chronological order because the format
 ml>> doesn't allow for accurate time stamping and many folk use local time
 ml>> with no UTC offset indicator...

 DE> The only time the tosser has to deal with HMB is for Netmail
 DE> or for message base maint. ALL Fido echos go to JAM bases.

FWIW: /ALL/ my message areas are JAM... netmail, local, usenet, echo,
mailing lists, etc...

 ml>> there are methods of creating indexes for ascii files... as for
 ml>> having all the areas in one database file, i see the benefits
 ml>> and the drawbacks... i've lost a full hmb before... 200 areas
 ml>> gone... poof! right into the bitbucket... on the other hand, i've
 ml>> lost one or two JAM areas but not the entire base...

 DE> I know the feeling on that one.

knock on wood, its been quite a few years...

 ml>> oh, and don't forget the limits of the operating system of the
 ml>> harddrive format... just because the os or the format can handle one
 ml>> file up to 32gig or 4tera doesn't mean that the message base format's
 ml>> indexes can count or point that high...

 DE> That would be ONE BIG MESSAGE BASE DATABASE! :> What, all
 DE> messages from all echos for the past 20 years or something? :>

hehe, could be... in this network... however, consider a system with the
space that just simply doesn't pack and purge... they elect to keep all
messages in all areas... a live archive... i've seen it done in RAID 5
setups with some 100+gig of storage capability... it was a large setup for
a large international company, though...

 ml>> there is a point of diminishing returns... once a database gets so
 ml>> large, it takes as long or longer to search thru it... that's the
 ml>> point to split it into seperate bases... just like memory in your
 ml>> machine(s)... sure, the machine may handle 4Gig of RAM but is it
 ml>> really helping it to go fast or is it another behind the back sneak
 ml>> that intel and others are pulling (like the winmodems and winprinters)
 ml>> to give the processor something to do all the time?

 DE> I would not use 4GB in an intel based machine. Thats
 DE> rediclous. 1GB is plenty.

hunh? and here we are today with IDE drives in the 100+gig range and some
coupled on RAID5 setups... there are times and situations where one does
need that much storage capacity...

 ml>> they are basically the same thing... and its not a size constraint...
 ml>> converting 2 characters into 3 is always going to make the resultant
 ml>> output larger than the input was...

 DE> Actually, it's 3 into 4, but that is beside the point :> It
 DE> still increases the size. Going 2 into 3 would result in a
 DE> roughly 50% size increase. 3 to 4 is a roughly 33% increase :>

yeah, that's what i was thinking... its been a while since i dug about in
that code stuff... but it is that 13rd larger increase that i was speaking
of >

 DE>>> 1) Supports Win32 Long File Names

 ml>> why? i just showed you how to set up a hierarchy of directories for
 ml>> the message bases... long filenames are not a necessity, are they? i
 ml>> mean, are they /really/ =needed= just because another piece of
 ml>> software can handle them? surely that piece of software can also
 ml>> handle 8.3s? surely that piece of software doesn't base the display
 ml>> name of an area on the filename used to store the areas data?

 DE> See my comments above.

yah >

 DE>>> 2) Has a message base pack/purge/sort/index/etc.. feature

 ml>> commonly available...

 DE> I would hope so :>

hehehe...

[trim]

 ml>> what's wrong with a gap in the area numbering? ra can/will display the
 ml>> areas all tight up together in a sequential fashion without the gap if
 ml>> done right... myself? i prefer the gaps because then i can tell folk
 ml>> that the space oriented areas are in the 300's, the news groups are in
 ml>> the 1000's, the political areas are in the 2000's, etc... again, its
 ml>> another way of catagorizing and seperating things in a logical
 ml>> method...

 DE> That I can see and it will eventually happen here. But it's a
 DE> low priority.

AIR, in RA, its a simple matter of the RDX file... ISTR that you delete the
RDX file and let a new one be created with all the empty records being
deleted from the message base definition area... however, that would toss
FMail for a loop, though... its one reason why i've stayed with FE...

 DE>>> 4) (optional. Nice, but not necessary) Read a fidonet nodelist
 DE>>> (text/v6/v7/etc...) and allow routing commands for mail based
 DE>>> on nodelist flags, or lack thereof.

 ml>> i think see the reasoning behind this desire but without a more
 ml>> specific example, i'm not sure... i don't think you are talking about
 ml>> the RVIA stuff in the nodelist but if you are, you should know that
 ml>> the testing period for it has expired and that it should already have
 ml>> been removed from the nodelist... besides, the phonebook isn't where
 ml>> you go to find a map of directions to someone's house, is it?

 DE> Not Riva, but Capablity flags. For example, route any mail to
 DE> someone who flys the IBN flag to them directly. Anyone NOT
 DE> flying that flag gets mail routed through my hub.

ummm... sure, that could be done... but then you also have to look to see
if they are CM and/or be able to take into account their online times if
they are not... this is one reason why routing should have been more stable
that it has been over the years... in my case, i simply mark those as
DIRECT and they can't be routed... but that also depends on your mailer,
too... FD types can do it but BSO types have to be done another way...

 ml>> in any case, this last one also deals with how you handle routing
 ml>> passthru mail... some use their tosser as you are seemingly
 ml>> indicating
 ml>> that you want to do... others mailers handle their routing and there's
 ml>> a third group that route some stuff with their tosser and the rest
 ml>> with their mailer...

 DE> Well since Argus won't handle ANY routing, for me it has to be
 DE> done via tosser.

true... many of the new mailer (and bbs packages) still have a long way to
go to catch up to the capabilities that the DOS mailers have had... its
another reason why i've stayed with FD and RA and just run them via telnet
with a virtual modem shim... i've yet to find anything that approaches them
in their capabilities in this area... at least to my satisfaction...

 ml>> could you be a bit more specific with your example about routing
 ml>> based on a flag??

 DE> See Above. I just did :>

>

 ml>> well, since this is the allfix_help echo, i don't think that fmail
 ml>> support is available in here >  maybe in the
fmail support echo?

 DE> I finally got FMail working ok. Not great, but works good
 DE> enough. Now if you can show me a good way to handle your
 DE> file/dir naming conventions above, then I could likely stick
 DE> with FastEcho and not need to register FMail (which would make
 DE> me happy).

if you are thinking about that possible directory and filename clash, i
showed how that won't happen at the very top of this message
>

)\/(ark