12

...besides relabelling the disk to 'Lazarus' and helping the Saddam virus spread?

I know it was supposed to 'fix' corrupted disks that were ejected during a write operation. I don't think I've seen a single case where it would actually succeed; usually it only made things worse by breaking the label by which the disk would identify. There were tools, like 'disk doctor', that would successfully repair the corruption, but the OS-provided disk-validator seemed to be a totally misguided effort.

So, actually, what did it try to do, and why did it usually fail?

Improve this question
4
  • I'd like to see some background on this question. What software is disk-validator part of? What does the manual say?
    – tlindner
    Commented Apr 30, 2016 at 20:30
  • 2
    @tlindner: Disk-validator was a part of AmigaOS/Kickstart, it was supposed to work pretty much transparently so it didn't appear in any simple docs 'for the user', and one of its quirks was that after it was loaded by the OS from any corrupted disk, automatically without user interaction other than inserting the disk, it would be saved by the OS to any consecutive corrupted disk not containing it before attempt to repair it. A behavior happily hijacked by virus writers. All the virus had to do was to mark any inserted disk as 'invalid', the OS did all the rest of the work copying the virus.
    – SF.
    Commented May 1, 2016 at 7:14
  • @SF. fortunately they fixed that with the advent of AmigaOS 2.0 and onward. Those more modern Amiga operating systems had their Disk-Validator in the Kickstart ROM and would never attempt to load it from the file :L/Disk-Validator anymore. That means those kind of virii were unable to load and spread on the newer OSes. Unfortunately it also meant that disks infected and changed by the Saddam virus appeared invalid on those newer OSes. You would need to clean them with an Antivirus that knows the specific malware and undoes their change before the disk can be used again.
    – blubberdiblub
    Commented May 1, 2016 at 7:28
  • 1
    Also, the Lazarus label originated from Disk Doctor, not from Disk-Validator.
    – blubberdiblub
    Commented May 1, 2016 at 13:18

2 Answers 2

Reset to default
9

It would work in simple cases where there was a crash during a write in such a way that it would simply not finish.

What would happen as part of a write was that the bitmap(s) indexing unused blocks (0 = used, 1 = unused) would be invalidated, the write would proceed, the bitmap updated with the information about newly used blocks and marked as valid again.

If a crash occurred while the bitmap was not marked as valid, then the disk would be read-only to the user and OS apart from the disk-validator. It would then go through the disk to rebuild the bitmap and mark it as valid, after which the disk would be read/write again.

The unfinished file would have to be regenerated (or "part-salvaged" by the user).

Now, a less controlled crash/error (such as a power loss or accidental eject while writing?) might be more unpredictable and more likely to trash other data, perhaps including metadata about the directory layout; this would require more specialised repair programs to see "invisible files" etc., which I do not have under-the-hood knowledge of..

Improve this answer
1
  • Those more intricate file system repair/salvage programs usually scanned all blocks of the disk. File system metadata blocks have certain values at fixed places that can be used to distinguish them. The program would build a list of metadata blocks thus found, among which would also be false positives and remnants of once valid but now outdated and unused blocks. It would then try to determine from the intact part of the metadata tree which of the orphaned blocks are likely current valid ones, which are likely outdated ones and which are likely false positives.
    – blubberdiblub
    Commented Apr 30, 2016 at 17:43
7

From what I can tell, it succeeded more often than not. But when it succeeded, it did so silently (apart from audibly using the disk for some time) and you could just go on working as long as you didn't need to write to disk early. Very likely you either didn't notice or you forgot about those instances over the years.

It was only very vocal when you left the disk write protected or when it otherwise failed to complete its task and those are the instances that we remember the easiest.

As already explained in nsandersen's answer, its task was to get an invalid block allocation bitmap back into a valid state. In order to find out which blocks are in use, it scanned through all directories, starting from the file system root, taking note of all metadata blocks (including all extension blocks) and the locations of the file data blocks and marking all those as occupied while marking all other as free. (Which also explains why it would take longer on a disk with a more complicated directory structure and on (fragmented) file systems where the metadata blocks are spread out over a far distance.)

But it could only finish its task if it didn't find any invalid blocks or inconsistencies during the process. If it stumbled upon an inconsistency, it would stop, report its failure and leave the disk unchanged. You were then unable to write to the disk until you used a more sophisticated repair / salvage program on it.

As an example of those repair programs you mention Disk Doctor. From my experience, it was often unable to successfully repair an invalid file system. Not seldom it even did changes to the disk that made the situation worse and you lost more data than necessary. Usually you were better off resorting to third party programs like DiskSalv.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .