...
 BS> I bet if you look in to the storage procedure in 
 BS> vm_run.c, you might be thinking, "is this right?"

Ok.  I'll need to add that file to what I should look at over the weekend.

 ...
 BJ> Unforuantely, due to the amount of time I have for this, I have the 
 BJ> needed patience....  I'm barely getting around to 
 BJ> repling to the echo 
 BJ> mail at this point in time.....

 BS> Okay. That's kinda sad..

With the start of the new school year, I have been busier (sp?) than I expected.  

 BS>>> But QWK upload doesn't work well :( 

 BJ>> Try local console (bin/max -k) mode.  If I remember correctly, this 
 BJ>> gets around the problem with file transfers and will allow you to 
 BJ>> test out .QWK format without the file transfer code working.  

 BS>> The file upload doesn't work at all1

 BJ> Ok.  I haven't tested this idea.....  

 BS> Okay, gotta rewrite.. It works _sometimes_ if you're lucky.

Save a copy of the upload that works.  And then a copy of a small upload
that doesn't work.  Then use OD to dump out the contence of each file and
verify that both files are what they should be (CRC wise, etc.).  Once both
files are verified as good, then we know that the problem is with either
the user's program used to upload the file, the link between the user and
the BBS (the TCP/IP path if not using the local console, direct file read
if using the local console methoid I've mentioned), or with the Maximus BBS
code.  I suspect a number of possible sources of problems.  CR/LF is one. 
Non-clean 8 bit data path is another.  Character interpretation - changes
by the user program is another.  

It might be usefull to put a debug log in Maximus to log what the character
stream that Max received was, and then compare that with what was sent. 
Then we can determine if things like ASCII NUL or ASCII DEL are causing
problems, or a CR/LF issue is there, or if an 7 vs 8 bit TCP/IP path is
part of the issue.

This is just the start of my thoughts on debugging this issue.

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01