I developed a technique to test the status of floppy drives from a batch file a couple of years back that was published in PC Magazines, "User to User" column. Unfortunately, it could only test floppies and failed with CR-ROMs, network drives and did not work under Windows 32 bit file access. The following procedure uses a similar technique, but is now extended to work with all types of drives.

Normally testing a floppy or a CD-ROM drive can be rather problematic, if there is no disk loaded. The results are a little less than 'user friendly', requiring intervention to deal with the much hated "Abort, Retry or Fail?" (ARF) question. The solution is to use the undocumented /F switch with COMMAND.COM to run the test. This switch causes any disk error to default to the "Failed" condition, the same as if the user pressed the 'F' key in response to the ARF. Why do you suppose that the /F switch is still undocumented even though it has been in every version of DOS since 3.0? I certainly don't know. By the way, it works fine for output port (COM, LPT, etc.) errors too.

The %COMSPEC% line does nearly all the work; invoking COMMAND.COM with the VOLume command, filtering the output through FIND and finally setting an ERRORLEVEL with CHOICE to mark the result of the test. Error messages generated when floppies or CD-ROMs don't have disks loaded are suppressed by CTTY commands before and after the COMSPEC line. The first sends output to the NUL device and the second restores output to the display (CONsole).

The last four lines demonstrate how the calling routine can act on the results of the test. They are not a necessary part of the procedure. I have another page that explains the use of CHOICE to set ERRORLEVELs.

So, the procedure shown above solves all the problems, right? WRONG! That's what I thought until Michael Donn (an alt.msdos.batch netizen) was kind enough to point out a problem with network and RAMdrives. Since the whole idea is to make the routine as bullet-proof as possible, I am forced to offer yet another approach, based on the first, but extended to cover these two additional conditions.

The problem with network and RAMdrives is that the test used above counts the number of times the word 'Volume' appears in the output from the VOL command. Two lines are returned in DOS 6 (among others) for a physical drive that is ready, one with the volume label and a second with a serial number. Neither network nor RAMdrives return serial numbers, so the test fails. Certain other 'logical' drive types may also fail to return serial numbers.

The work around that I originally offered (TestDrv2.bat) was to perform a second test using the DIR command any time the volume test returns an ERRORLEVEL below three. A VOL test checked for the existence of the drive, while the DIR test checked its readiness. However, recently I realized this was more complicated than necessary and I have streamlined it back to a simple, case insensitive, test for the letter 'D' as shown in TestDrv3.bat, below.

Why it took more than three years to figure out this replacement, I just don't know.

The development of this latest routine followed my examination of an approach posted by Bill James in the alt.msdos.batch newsgroup, in which he used the characteristics of the XCOPY32.EXE utility to test drives. This works fine under the Win 95/98 GUI, but fails to handle empty removable media drives correctly in 'pure DOS'.

His use of the external utility, XCOPY, did prompt me to examine some other standard external utility. Testing of the Scandisk.exe utility, introduced with DOS version 6.0 proved fruitful. Run from a command prompt or batch routine, Scandisk with the /Fragment switch, does perform in a way that makes drive testing possible. The following routine demonstrates its use.

The idea of TestDrv4 is to test the contents of Scandisk's error messages sent to the temporary text file for particular characters or words. Counting their occurrence with the FIND filter provides the needed distinctive. Piping this count into CHOICE gives the desired errorlevel results as in the earlier routines. Note that TestDrv4 provides additional utility, in that it can be used to sniff out network drive mappings at the cost of some additional complexity.

TestDrv4 must be called with a single alpha character as its lone argument. Adding a colon to the TestDrv3 routine has no ill effect, but TestDrv4 will fail for empty removable media drives if a colon is added. I have tested it with DOS 6.2 and Win 98 so far.