Before talking about whether SpinRite was ever any good or not, it's good to consider the hard drives that were in use at the time it became popular. These earl

Before talking about whether SpinRite was ever any good or not, it's good to consider the hard drives that were in use at the time it became popular. These early drives pretty much all came with a ST506 interface, as well as in MFM and RLL variants (there were also ESDI and SCSI drives, but since these were exclusively used on high-end systems, they're safe to ignore due to their rarity. The distinction between MFM and RLL can also be ignored, as RLL drives were really only differently-specced MFM drives that allowed the controller to do some rudimentary compression on the bitstream in order to expand usable capacity). The thing about the ST506 interface is that it was really, really simple: you (the disk controller) could seek to a track, the drive would tell you when that was done, then you could select a head, and the drive would tell you when the start of the track passed under that, and then you could read or write bits to the thus-selected cylinder. Again ignoring some finer points like precompensation and read recovery, you really only cared about three drive parameters: the number of tracks, the number of heads (multiplying these gave you the number of cylinders), plus how many bits you could approximately write to each cylinder. If you take a look at the OEM manual for the ST225 (a very popular ST506 drive at the time), the simplicity just jumps at you: https://archive.org/details/seagate-st-225-oem-manual-oct-85 https://archive.org/details/seagate-st-225-oem-manual-oct-85 You'll also notice, though, that there is no real mention of 'sectors' anywhere just yet. That's because that wasn't a drive concept, but something managed by the controller, which was responsible for dividing cylinders into sectors holding 512 bytes of user data. That division would mostly be timing-based, but to allow for error detection and recovery, the controller would add some metadata to each sector: typically, a sector number and simple checksum, which was sufficient to perform timing recovery and retry reads as required. After connecting a new drive to a given controller, the user would therefore need to run a 'low level format', typically by invoking some code in the controller card ROM BIOS, or by running a vendor-supplied utility: this would then go through all cylinders and write the metadata, including all-zero user data, for each sector. For some sectors, this would yield a write fault, and such sectors would be added to a bad sector list, resulting in a drive with a capacity slightly below that advertised. Another parameter used for this low-level format was the 'sector interleave': instead of dividing a cylinder into sectors 1-2-3-4-5 and so on, the controller would do something like 1-100-200-300-400-2-101-201-301-401-3, with the exact numbers depending on the capacity of the drive, obviously, but mostly the speed of the host system. Because PCs were really slow at the time, demanding tasks like 'reading 2 sectors sequentially' would result in a miss on the second sector, meaning having to wait for an entire disk rotation before trying again. By interleaving sectors, this miss could be avoided, greatly improving performance, but also hindering performance in case the selected interleave never or no longer (i.e. after an upgrade) matched the host speed. Now, let's turn to SpinRite. Its author, Steve Gibson, understood the relationship between disk, controller and BIOS really well, and cleverly improved on the default experience, which only provided destructive low-level formatting and virtually no diagnostics tools. By combining this understanding with a database of drive parameters and controller BIOS details (mainly: what is the address and calling convention of the per-sector read, write and format routines) and a fancy GUI, he provided some real value to early hard drive users. Initially setting up a drive with SpinRite required no obscure DEBUG commands or utilities, nor guessing of the optimal sector interleave: SpinRite would perform some tests to figure the latter out, and then perform the low-level format, with a progress bar and all, which was unheard of in vendor tooling. Even better, Gibson figured out how to do a non-destructive low-level format, and that was the true SpinRite superpower. Upgraded to a faster system and now stuck with a nonoptimal sector interleave? SpinRite could fix that for you! Did your drive degrade a bit (due to platters/heads getting out of alignment and/or the stepper motor wobbling), SpinRite could literally restore it to factory-fresh performance! So, fancy GUI and incredibly impressive marketing aside (which Gibson was really good at as well), the basic algorithm that gave SpinRite its legendary reputation was quite simple: invoke the controller BIOS to read all sectors for a few tracks into a ring buffer in RAM (employing as many retries as needed to recover the data if at all possible), re-order those sectors if changing the sector interleave, invoke the controller BIOS low-level format for the first half of these sectors (because you don't want to low-level format too close to data you haven't touched yet!), then write back the data. Rinse, repeat, with some clever handling of bad sectors and saving checkpoint data to an unused disk sector, so restarting the system during a SpinRite run rarily resulted in data loss. This worked really well for a long time, but broke down completely when disks stopped using ST506 and migrated to "Integrated Drive Electronics" (IDE) interfacing. When using IDE, the responsibility for managing "sectors" moves from the controller to the disk itself. This greatly simplified the controller-to-disk interface, as the former no longer needed to know about track or head counts: instead, the disk simply presented sequential sector numbers, LBAs. LBA-to-physical-sector mapping became a disk vendor responsibility, which it remains to this day in newer interfaces like SATA, SAS and NMVe. IDE did away with a number of things, including sector interleave, which due to the increase in host speeds was no longer relevant. But it also made it impossible to perform a 'low level format' type operation, since that was now fully a drive responsibility. Of course, the drive firmware might provide equivalent functionalty to the controller, but, especially in the early days of IDE, it definitely didn't do so. This meant that SpinRite's magic no longer worked on IDE drives. Sure: it could still attempt to read all your data (and with enough retries, that did allow for data recovery in some situations), then write it back (which might trigger a sector re-allocation in the IDE drive, but who knows), but that was about it. This did not stop Gibson from continuing to market it, and 'The Internet' from continuing to embrace it. There were rumors of SpinRite having special backdoor access to IDE controllers and such, but that was basically all nonsense. SpinRite was now `ddrescue` with some `chkdsk` and `smartmontools` thrown in, just with a much nicer user interface. So, SpinRite started out as an extremely useful tool that was worth its money, then degraded to a no-longer-magical shell of its former self that continued to be over-hyped, often passionately, for about a decade after the point it should have faded into obscurity. There is a lot of hazy discussion around these facts, but simply by looking at how the underlying tech evolved, the picture becomes pretty clear...