dold@mitisft.Convergent.COM (Clarence Dold) (03/25/89)
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
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/28/89)
In article <597@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: >> :loop >> copy /b newfile+zerofile newfile >> goto loop > >But the .bat is so slow as to be useless. There is a space-time tradeoff. If you frequently need to zero out disk blocks, time may be your greatest concern. But if you only do it once every few months, the batch file is the way to go. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu