Why did ScanDisk exist?

Question

As far as I can tell, CHKDSK has been part of DOS and Windows since day one. However, in later versions of DOS, CHKDSK was shipped along side ScanDisk. As of Windows 98, running CHKDSK will result in the program printing a recommendation for ScanDisk instead.

In later versions of Windows (such as XP), ScanDisk had disappeared entirely, having been replaced by CHKDSK.

That said, why did Microsoft originally make ScanDisk, and why did they scrap it? Did ScanDisk do something that CHKDSK couldn't do? The Windows 98 version of CHKDSK says "SCANDISK can reliably detect and fix a much wider range of disk problems." Was this true? If so, what additional problems could ScanDisk fix?

Answer 1

There are quite a few differences between the MS-DOS CHKDSK and ScanDisk, beyond the latter’s friendlier interface.

• ScanDisk can “repair” cross-linked files, i.e. files which end up pointing (entirely or partially) at the same cluster chain — this always involves data loss, but it’s better than CHKDSK which would only tell the user about the problem (users then had to copy the files manually and delete the originals).
• As its name indicates, ScanDisk can scan the disk surface, as well as verify the file system’s integrity; it will repair files stored on bad sectors (as far as it can — the data stored on the unreadable sectors won’t be recovered), and it can also flag sectors which take too long to read (which may indicate they’re about to become unreadable). Sector recovery previously involved using the RECOVER tool.
• It can repair invalid media descriptors. With CHKDSK, this involved using a disk editor (as documented by Microsoft!).
• It copes with directories containing more than 32,767 entries, unlike CHKDSK.
• ScanDisk and CHKDSK deal with attribute corruption somewhat differently. Thus ScanDisk will ignore volume labels with data (which usually indicates that they are really files whose volume attribute has been set incorrectly), whereas CHKDSK treat the corresponding clusters as unlinked and recover the data. Similarly, ScanDisk mis-handles files whose directory attribute has been set, and this is one of the few recovery scenarios where Microsoft recommended using CHKDSK rather than ScanDisk.
• ScanDisk is customisable, and Microsoft provided a decently-documented configuration file.
• Last but most certainly not least, ScanDisk can analyse compressed volumes. When DoubleSpace was introduced with MS-DOS 6, CHKDSK wasn’t extended to cope with compressed volumes; instead, it cooperated with the DBLSPACE utility. ScanDisk was introduced with MS-DOS 6.2 and supports compressed volumes directly (DoubleSpace in version 6.2, DriveSpace in version 6.22), and the CHKDSK cooperation was removed.

This begs the question, why not add all those features to CHKDSK? I can think of two reasons:

• Microsoft wanted to have a “user-friendly” disk checker, matching the new DEFRAG tool (which had been added in MS-DOS 6). But changing the interface of CHKDSK would have broken backwards compatibility... (In particular, CHKDSK wasn’t used only to check the file system; since it reported on available memory, users commonly used it for that purpose, since before MEM appeared in MS-DOS 5, that was the only way to determine that information using DOS-provided tools. There were thus batch files relying on this feature.)
• CHKDSK was written in assembly language (and you can now see the source code for version 2.0), and I imagine the engineers involved balked at the idea of adding all the features above to an assembly-language program, or at least found it easier to re-write everything in C (which is what ScanDisk was written in).

ScanDisk was never added to the Windows NT line of operating systems, so when that took over the full Windows family (with Windows XP), ScanDisk disappeared. Windows NT had its own, NTFS-capable version of CHKDSK.

Answer 2

The (at least original DOS versions of) chkdsk checked the integrity of the FAT filesystem. Say, a reboot occurred interrupting a disk write, chkdsk e.g. could find correspondingly corrupted files and clean up. scandisk, on the other hand, could also perform tests of the physical disk surface by performing read and write operations, and it could identify bad blocks and exclude such blocks from being used for file storage.

Answer 3

Scandisk appeared in msdos 6.20, to cure the problems that dblspace in 6.00 was doing to people's data. It's essentially a cutdown version of Norton Disk Doctor (NDD).

When Windows 95 came around, they continued to use it for the next rolling experiment: fat-lfn. Nuts&Bolts included a competing product 'diskmind', as dmdos.exe and diskmind.exe. You could fetch this at MGDx site.

By the time Win95 came out, microsoft were trying to wean people off the command prompt, and scandisk was better at that than chkdsk.

IBM were not so keen, and so even in gui systems like OS/2, they made the distinction between 'DOS' and 'OS/2' prompts, and never pretended one was the other.

Answer 4

I remember Scandisk as having appeared around the time of Windows 95. In that era, booting was sufficiently slow that many machines were left on for extended periods of time while unattended, and hard drives would typically spin as long as they had power; reading them would thus not contribute meaningfully to wear. Given these factors, there may have been some benefit to scanning hard drives for errors while a system was idle. If one had multiple copies of a file and one went bad, discovering that could alert one to the need to back up one of the surviving good copies. Microsoft certainly saw such a benefit, since one of scandisk's main functions was to start up when the system was unattended, and stop once the system was in use again.