It looks like a bug in both DEBUG and the kernel. What happens is the reference count in the SFT gets too high. 1. open: 1 2. int21/ax=4b: 2 3. int21/ax=55: 3 (this function called by debug)
then: 4. int20: 2 5. int21/ah= 3e: 1 ... and the file still isn't really closed
If you do the redirection again then it will use new sft entries. Just do the above a couple of times and you'll see that opening a file gives an sft idx entry in the PSP that is higher and higher... in other words, leaked file handles...
Wow! What a nightmare! :-(
It doesn't hurt to commit (sync) the file though so with the patch below the problem is "solved".
And this is so for both MS-DOS DEBUG and FreeDOS DEBUG, as it seems from your and my tests...
That's strange. Then MS-DOS DEBUG would also leak handles...
Seems so, because applying your patch FIXED the problem with MS-DEBUG too! Congratulations! :-)
So far so good. But when the input debug SCRIPT contains just these lines:
r q
doing DEBUG < SCRIPT starts to output NULs and BEEPs! Pressing Ctrl-C stops it, but then the SCRIPT file has that ^C appended! This is like a similar bug we had - do you remember? :-(
But when SCRIPT has only CARRIAGE RETURNs as line terminators (without line feeds), it's OK!
So we have yet another TWO bugs to fix :-(
Lucho
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
