Bug in stubify.c

Bug in stubify.c

Post by Molnar Lasz » Thu, 04 Jul 1996 04:00:00



Hi!

I've found a bug in stubify.c. This caused lost clusters when the
disk became full, or write() failed (fortunately I noticed it on a ramdisk).
The problem is, that it tries to delete the output file before closing it.
(As the Interrupt List 50 says this is not a problem with dr-dos, or when
share.exe is loaded.)

Bye, ML

So here is the diff:

-------------------cut----------------cut--------------cut---------------
*** stubify.co  Sun Nov  5 22:32:32 1995
--- stubify.c   Fri Jun 28 01:17:10 1996
***************
*** 155,161 ****
      {
        perror(ofname);
-       unlink(ofilename);
        close(ifile);
        close(ofile);
        exit(1);
      }
--- 155,161 ----
      {
        perror(ofname);
        close(ifile);
        close(ofile);
+       unlink(ofilename);
        exit(1);
      }
***************
*** 163,169 ****
      {
        fprintf(stderr, "%s: disk full\n", ofname);
-       unlink(ofilename);
        close(ifile);
        close(ofile);
        exit(1);
      }
--- 163,169 ----
      {
        fprintf(stderr, "%s: disk full\n", ofname);
        close(ifile);
        close(ofile);
+       unlink(ofilename);
        exit(1);
      }

 
 
 

Bug in stubify.c

Post by laurin keith davi » Fri, 05 Jul 1996 04:00:00


Quote:>disk became full, or write() failed (fortunately I noticed it on a ramdisk).

umm, could someone please, tell me what a ramdisk is. i have seen this many
times, and yet, i can't find out what this means.
----------------------------------------------------
\anyway, thanx for being such a great listener!    /
\you're a swell person (despite what they say) and /
\it's been real groovy!                            /  
\                               htiek              /    

\mybeeper#forthosewhocare  <><>support your local  /
\18007963087               <><>internet provider.  /
\visit me at http://www.*highway.net/~laurin   /
----------------------------------------------------  

 
 
 

Bug in stubify.c

Post by Dominique Micoll » Fri, 05 Jul 1996 04:00:00



: umm, could someone please, tell me what a ramdisk is. i have seen this many
: times, and yet, i can't find out what this means.

A ram disk is a part of the memory used as a hard disk drive, ie with fopen,
fwrite, ....

This implies the use of a dedicated driver.

Pro : very fast compared to an actual disk drive, as the ramdisk driver use
memory access

Cons : the data are stored in volatile memory : you may lost them if you
do not backup the files on an actual hard disk.

This was very useful  when there was not DJGPP as it was a way to temporary
store quickly data from programs which cannot store them in 640K.

Today, I think that using a ramdisk which DJGPP is not a good idea because
the consumed memory is lost for DJGPP : the program will swap more frequently.
Am I right on this last point ?

--
      Cordialement

************************************************
* Dominique MICOLLET                           *
* Laboratoire LIESIB                           *
* Universite de Bourgogne                      *
* 6 Boulevard GABRIEL                          *
* BP 138                                       *
* 21004 DIJON CEDEX                            *
* FRANCE                                       *
* Tel     : /33/80-39-59-27                    *
* Tfx     : /33/80-39-60-43 /33/80-39-59-99    *

************************************************

 
 
 

Bug in stubify.c

Post by Molnar Lasz » Sat, 06 Jul 1996 04:00:00


: Today, I think that using a ramdisk which DJGPP is not a good idea because
: the consumed memory is lost for DJGPP : the program will swap more frequently.
: Am I right on this last point ?
:
Not really. I use a program that is a combined disk cache AND ramdisk. It
shares the memory dinamically between the cache and the ramdisk. If I
allocate 5 Megs of XMS for this program I have a virtually 5 Megs
large ramdisk and a virtually 5 Megs large cache. The rest from my 16 Megs
can be used by DJGPP.

Bye, ML

Ps: This program is called COMBI. Search for combi118.zip (or similar) if
interested.  

 
 
 

Bug in stubify.c

Post by Boon van der » Tue, 09 Jul 1996 04:00:00




>:Today, I think that using a ramdisk which DJGPP is not a good idea because
>:the consumed memory is lost for DJGPP : the program will swap more
>:frequently.
>:Am I right on this last point ?
>Not really. I use a program that is a combined disk cache AND ramdisk. It
>shares the memory dinamically between the cache and the ramdisk. If I
>allocate 5 Megs of XMS for this program I have a virtually 5 Megs
>large ramdisk and a virtually 5 Megs large cache. The rest from my 16 Megs

       don't you restrict that ^^^^^^^^  to about 2 or 3MB max?
Quote:>can be used by DJGPP.

But still DJGPP uses tmp-files, which can be stored on a reasonably large
ram-drive (at least 3Meg) And than a (2meg) cache for the hard-drive.
I dare to say that DJGPP got faster after adding the ram-drive. Even with
only 12 MB of RAMspace. (I think I read a recommendation for my
configuration somewhere in the FAQ (only it said 16meg of RAM))

hth,
 Robert

Quote:>Bye, ML

>Ps: This program is called COMBI. Search for combi118.zip (or similar) if
>interested.  

I have tried it, too bad it didn't work on my pc (something about DosVersions
and plain crashes).
 
 
 

Bug in stubify.c

Post by Molnar Lasz » Tue, 09 Jul 1996 04:00:00



: >Not really. I use a program that is a combined disk cache AND ramdisk. It
: >shares the memory dinamically between the cache and the ramdisk. If I
: >allocate 5 Megs of XMS for this program I have a virtually 5 Megs
: >large ramdisk and a virtually 5 Megs large cache. The rest from my 16 Megs
:        don't you restrict that ^^^^^^^^  to about 2 or 3MB max?

As I said it dinamically shares the memory between the cache and the ramdisk
(So if you have some files on the ramdisk which occupy 1 Meg, then you will
have a 4 Megs large cache. If you delete a file from the ramdisk, Combi will
use its memory as cache, and if you copy a file to the ramdisk, it will
decrease the size of the cache).

: But still DJGPP uses tmp-files, which can be stored on a reasonably large
: ram-drive (at least 3Meg) And than a (2meg) cache for the hard-drive.
: I dare to say that DJGPP got faster after adding the ram-drive. Even with
: only 12 MB of RAMspace. (I think I read a recommendation for my
: configuration somewhere in the FAQ (only it said 16meg of RAM))

Yes it's really faster.

: >Ps: This program is called COMBI. Search for combi118.zip (or similar) if
: >interested.  
: I have tried it, too bad it didn't work on my pc (something about DosVersions
: and plain crashes).

There is a command line switch, which will disable this version check
(read the docs!)
It works fine with MSDOS 6.22.

Bye, ML

 
 
 

1. RAMdisk (was: Bug in stubify.c)


Another disadvantage (that frequently goes overlooked) is that ramdisk
usually is quite small and can be easily filled with large temporary
files, after which point programs start mysteriously to fail...

2. Dial-Up keeps popping UP

3. Fw: Bison and [f]lexical tie-ins

4. configuring sendmail

5. I need Ctrl-Ins in BC 3.1 again

6. CKOKER32.EXE - Thanks Everyone !

7. Trapping Ctrl-Alt-Del and Ctrl-Alt-Ins

8. WinME or Win2K?

9. Switch to COMMAND.COM ins

10. Plug-ins......?

11. Bison and [f]lexical tie-ins

12. error: cannot exec 'stubify'

13. strip.exe and stubify.exe - what are they for?