Subj : Another filearea question To : Mvan Le From : mark lewis Date : Fri Jun 08 2007 12:41 pm SH>> Okay then I'm not out to lunch. :) I just mis-read SH>> what you said. I've almost got an updated MFM with SH>> file_id.diz importing working, just being held up by SH>> time removing the fossil / door code to MFM which is SH>> causing a giant headache in the OS/2, Win32 port. MvanL> Man I just use the Hurl menu option. what has that to do with removing fossil and door library code from the package in question? hurl is used to move a file from one location to another along with its description... that has nothing to do with the original question and discussion about MFM importing file_id.diz files... [Arrowbridge I] MvanL>> Probably because it's looking for dorinfo2.def for node 2 etc. MvanL>> Atleast that's how AB-I works ie. dorinfo.def. I'm assuming MLvan>> AB-II works similarly. SH>> Exactly. MLvan>> copy %max%\dorinfo1.def .\dorinfo%1.def that is exactly how one does it with a system that doesn't create dorinfo2-9 files... now, what does one do when they are running 10 or more nodes? the dorinfox.def standard wasn't thought thru very well... i've seen implementation that use hex and as such can support up to 16 nodes... i've also seen implementations that support base36 which is also limiting on a large multinode system... then, there're those that start dropping letters to make room for numbers... ie: dorinfo1.def dorinf22.def dorin134.def like i say, not very well thought out... but it is way way way too late to do anything about it now, too... i tried some 15 years back but all anyone wanted to do then was spout the existing standard and do nothing about fixing or enhancing it... [trim] MvanL>> Apparently people adopted the numeral in dorinfo#.def to MvanL>> be a node designator when it was never meant to be. It's MLvan>> probably a "dorinfo" dropfile specification version number. hunh? you can provide documentation to this? i'd like to read it because nothing like it was ever presented or found in all my research years ago... everything i found showed that the number _was_ the node number... some bbs systems got around the 9 node limitation by creating dorinfo1.def for all nodes, though... and that's no real problem if the door can look in a directory other than its own for the drop file... ie: somedoor c:\bbs\n1 where c:\bbs\n1 is where the dropfile, whatever is being used, is located... c:\bbs\n42 for node 42... no copying or overwritting and no possibility of things going wonky if two users enter the door at the same time... )\/(ark * Origin: (1:3634/12) .