Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdahl!pyramid!ctnews!mitisft!dold
From: dold@mitisft.Convergent.COM (Clarence Dold)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: v02i004: zerodisk, erases unused disk blocks
Message-ID: <597@mitisft.Convergent.COM>
Date: 24 Mar 89 20:55:56 GMT
References: <6250@bsu-cs.UUCP>
Organization: Convergent Technologies, San Jose, CA
Lines: 42

in article <6250@bsu-cs.UUCP>, creps@silver.bacs.indiana.edu (Steve Creps) says:
>Rahul's editorial:
> Here's a small batch file that achieves a similar result.  Call it

>      :loop
>      copy /b newfile+zerofile newfile
>      goto loop

But the .bat is so slow as to be useless.

I noted a couple of problems in a Medium Model application (MSC):

If argc == 2, a malloc is performed before the sprintf.
If arc != 2, no malloc is performed, but the sprintf is still tried.
Under MSC, this worked, UNIX didn't like it.

+	if (argc == 2) {
+		unsigned int l = strlen(argv[1]) + strlen(tmpfn) + 1;
+		if ((tmppath = (char *)malloc(l)) == 0) {
+			fprintf(stderr, "zerodisk: cannot malloc %u bytes.\n", l);
+			exit(-1);
+		}
+		sprintf(tmppath, "%s%s%c", argv[1], tmpfn, (char)0);
+	} else sprintf(tmppath, "%s%c", tmpfn, (char)0);

If I compiled under Large model, I could fill my disk, but under Medium, 
I had to cast write(), in order to get past 3.2M bytes.  Increasing 
BLOCKSIZE had no effect.
	while ((long)write(output, buf, BLOCKSIZE) >= 0) ;
+	while (write(output, buf, BLOCKSIZE) >= 0) ;
This strikes me as bogus, since the docs say that write returns an int,
but watching the value retrieved by fgetpos(), which you have no opportunity
to change, showed this to work... 

And neither MSC nor UNIX care much for return:
+	return 0;
	return (0);
-- 
---
Clarence A Dold - cdold@starfish.Convergent.COM		(408) 435-5293
		...pyramid!ctnews!tsdold!dold
		P.O.Box 6685, San Jose, CA 95150-6685	MS# 10-007