BJ> now there is over 2 Gb (actually 3,834,035,200 
 BJ> bytes, at the moment) free
 BJ> on the partition....  And I received a report from 
 BJ> a user that he couldn't
 BJ> upload because of lack of disk space.  Am I 
 BJ> correct that Maximus is using
 BJ> a signed 32 bit integer under OS/2 for seeing how much space in bytes
 SD> You are correct.
Just what I expected, especially based on results of other programs that try 
to show me how much space I have and have used.  (The totals are laugh-able.)
 SD> The best solution is to simply create a 1.8 gigabyte 
 SD> file and delete it once the drive starts filling up.
ROTFL.......
 SD> Seriously!
I under stand.....  Ok....  I'll probably do that *or* move my upload area to 
a "smaller" partition (where I have about 1.5 Gb free at the moment).  My 
attempt at not setting Max's disk space limit still resulted in uploads 
failing due to "no disk space".  Oh, well....  Your solution would also allow 
me to move Binkley's inbound path to the same drive....
 SD> You can create a huge file from the command prompt by doing this:
 SD> copy A+A+A+A+A+A+A+A+A+A+A B
 SD> copy B+B+B+B+B+B+B+B+B+B+B C
 SD> copy C+C+C+C+C+C+C+C+C+C+C D
 SD> ... and so on, where "a" is any file on your drive.
Ah, yes..... the good old file merge solution.
Thanks for the response!  
I guess I can thank the API with the old DOS OS code for this situation.  
 Surely no one was ever going to need a disk 
larger than 32Mb (especially since most were running off of floppy disk 
drives)......   ;(
Take care.....rfj.....
--- Maximus/2 3.01
---------------