Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!ns-mx!umaxc.weeg.uiowa.edu!williams
From: williams@umaxc.weeg.uiowa.edu (Kent Williams)
Newsgroups: comp.os.msdos.programmer
Subject: Re: How does del *.* work?
Keywords: del *.*
Message-ID: <3917@ns-mx.uiowa.edu>
Date: 14 Jan 91 15:16:10 GMT
References: <1991Jan8.123410.1564@en.ecn.purdue.edu> <2yoqV2w163w@bluemoon.uucp>
Sender: news@ns-mx.uiowa.edu
Reply-To: williams@umaxc.weeg.uiowa.edu (Kent Williams)
Organization: U of Iowa, Iowa City, IA
Lines: 28

In article <2yoqV2w163w@bluemoon.uucp> bytehead@bluemoon.uucp (Bryan Price) writes:
>DEL *.* doing it instantly??  You running on a 50MHZ '486 with a SCSI 
>drive?  I don't think so! :-)
>
>My MS-DOS version of rm is just as fast, and has more options.  The 
>possible difference that I see is that you may be getting a filename from 
>findfirst/findnext, then deleting it, then getting the next filename from 
>findnext.  I run through findfirst/findnext first, putting all the 
>filenames into an array, then delete them.
>
Once again, with feeling:

del <pat>

in COMMAND.COM uses the FCB delete function (13H) in order to nuke files.  It
allows '?' wild cards.  It is a DOS 1.0 function so it only works in the
current directory, so you have to parse off the path part, change directory
there, delete stuff, then change directory back.

It is much faster than any find-first find-next combination, which in
conjunction with delete-file tends to thrash the disk updating internal tables.



--
             Kent Williams --- williams@umaxc.weeg.uiowa.edu 
"'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams"
"This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"