is there a chkdsk type tool for CP/M?

[alank2]

I know the OS doesn't have one and probably many people just used PIP to copy all the files from one disk to another essentially creating a good filesystem, but was there any utilities that attempted to check and repair the CP/M filesystem that run inside CP/M?

[durgadas311]

I seem to recall seeing some attempts to do that, but can't think of a specific example.

If you have a corrupted filesystem and are trying to repair it, one possibility is to image the filesystem onto a modern computer and use cpmtools - which has a 'fsck.cpm' and other tools.

Unfortunately, there isn't a lot of information in a CP/M filesystem from which to reconstruct the directory. It will depend on the type of corruption. And, of course, success will depend on how much the disk was used while corrupted - as collateral damage can be severe.

Just re-copying the files over a corrupted disk won't necessarily fix it - you must start with an empty directory. When a disk is "logged in", CP/M will read all file entries and construct the in-memory allocation vector - to be used on subsequent file create/write operations. If some errant code corrupts the in-memory ALV, CP/M may double-allocate blocks and even allocate directory blocks to a file - typically destroying the directory. Recovery of the media usually requires re-formatting (or else you must re-write the directory sectors with 0xe5).

[Chuck(G)]

There are only two structural errors that would seem to be possible on a CP/M filesystem disk--the first is an out-of-range allocation block number is part of an entry and the second is where two entries share the same allocation block. I've seen the second type more than the first, but either is uncommon. 22Disk has code to check for both, but I'm not acquainted with a native program to check them, but there could be one out there.

[fritzeflink]

I have a dircheck.com for my NCR DM-V CP/M2.2

I haven't found the source for it, maybe it is from a usergroup disk.

As there are no usefull tools like checkdisk or other I only use dircheck for controlling.

[Peter z80.eu]

May be FINDBAD would help also, at least to find bad sectors (and allocate them in a file entry so these sectors would not be used anymore).
See http://ftp.gaby.de/pub/cpm/BigBoard_...k3/FINDBAD.DOC and http://ftp.gaby.de/pub/cpm/BigBoard_...k3/FINDBAD.COM ...

[Chuck(G)]

But FINDBAD check sectors for usability, which is very different from CHKDSK, which checks the structure of the directory for errors. There are more errors that can creep into a multi-level FAT filesystem than the flat filesystem that CP/M uses.

[Peter z80.eu]

But FINDBAD check sectors for usability, which is very different from CHKDSK, which checks the structure of the directory for errors. There are more errors that can creep into a multi-level FAT filesystem than the flat filesystem that CP/M uses.

I know the difference. But my opinion was, somebody was looking in general for CP/M floppy disk tools which could help to "repair" problems.

[Chuck(G)]

Okay, I can see what you were thinking. But, as I said, CHKDSK doesn't normally do a surface analysis; it just checks structure.

Over the years, I've discovered CP/M disks with out-of-range block numbers, and duplicate block numbers in the same file as well as two files sharing the same block number. Oddly, those aren't nearly as disastrous as FAT filesystem structural errors. Usually, you lose only one block's worth of data in a file with such errors. Things such as missing extents are okay ("sparse" files are legal) as well as strange characters in file names. Unerase is pretty simple, as long as the original data hasn't been overwritten.

In short, CP/M structural errors are far less common that FAT filesystem ones. You gain a certain amount of efficiency and versatility by using a linked structure, but that same added level of complexity sets the stage for more serious problems when things don't go right.

Recall, also that CP/M was spawned in the early days of floppy systems; hard disks were beyond the budget of most people and organizations. SC-DOS and MS-DOS came alone when hard disks were well established.

If you look at some competing operating systems in the CP/M era, allocation was contiguous, with each file being pre-allocated. This gives you efficiency in access (no fragmentation) and reliability (no advanced structures other than a directory showing size and starting sector), but imposes a penalty with regards to being able to extend files. Defragmentation/repacking the disk was usually done with separate utility. Depending on the application, this could work quite well.

CP/M's file structure is sort of a happy medium, geared toward the floppy user.

[alank2]

Good thoughts Chuck; I always find file system methods and techniques interesting.

[Svenska]

CP/M's file structure is sort of a happy medium, geared toward the floppy user.

Sadly, the file system structure is not part of the file system itself. It would have been much nicer if a disk could identify itself - without relying on the BIOS.