questions about a backup program for the MS-DOS environment

[Stephen Adams]

In article <12459 at wpi.wpi.edu> jhallen at wpi.wpi.edu (Joseph H Allen) writes:

   In article <1990Apr25.125806.20450 at druid.uucp> darcy at druid.UUCP (D'Arcy J.M. Cain) writes:
   >In article <255 at uecok.UUCP> dcrow at uecok (David Crow -- ECU Student) writes:
   >> [...]
   >>      - possibly a faster copying scheme.  the following is the
   >>         code I am using to copy from one file to another:
   >>
   >>            do
   >>            {
   >>               n = fread(buf, sizeof(char), MAXBUF, infile);
   >>               fwrite(buf, sizeof(char), n, outfile);
   >>            } while (n == MAXBUF);        /* where MAXBUF = 7500 */
   >>
   >Try:
   >     while ((n = fread(buf, sizeof(char), BUFSIZ, infile)) != 0)
   >		fwrite(buf, sizeof(char), n, outfile);
   >
   >By using BUFSIZ instead of your own buffer length you get a buffer size
   >equal to what the fread and fwrite routines use.  

   No, no, no Yuck!  Don't use the C functions, and don't use such tiny buffers.
   (no wonder it's so slow :-)

   Try (in small or tiny model):


	... 30 lines of *heavily* machine dependent C ...

To suggest replacing 5 (or 2) lines of working C that will run on
anything that runs C with 30 lines of `assembly code' that runs only
on a PC, with a specific memory model and C compiler is lunacy.

Especially as it is completely unnecessary.

The most important things are:

	+ the buffer size
	+ avoiding needless copying

The bigger the buffer, the less time you go round the loop.  I would
suggest using the open/read/write/close functions instead of stdio.h
for copying files.  This is because stdio does its own buffering:

	input -> infile's buffer -> your buf -> outfile's buffer -> output

with read/write *you* do the buffering:

	input -> your buffer -> output

Use a large buffer, preferably one that is a multiple of the block
size of the disk long.  It will go as fast as the 30 line wonder.  And
if it doesnt work you stand a chance of debugging it.