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?
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
is there a chkdsk type tool for CP/M?
- Thread starter alank2
- Start date
durgadas311
Veteran Member
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).
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)
25k Member
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
Experienced Member
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.
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
Experienced Member
- Joined
- Apr 21, 2016
- Messages
- 84
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_User_group/Disk3/FINDBAD.DOC and http://ftp.gaby.de/pub/cpm/BigBoard_User_group/Disk3/FINDBAD.COM ...
See http://ftp.gaby.de/pub/cpm/BigBoard_User_group/Disk3/FINDBAD.DOC and http://ftp.gaby.de/pub/cpm/BigBoard_User_group/Disk3/FINDBAD.COM ...
Chuck(G)
25k Member
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
Experienced Member
- Joined
- Apr 21, 2016
- Messages
- 84
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)
25k Member
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.
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.
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.
Chuck(G)
25k Member
When it comes to hosting on different platforms, all CP/M has really--is the BIOS. There were a few CP/M systems made that could be set for a number of different "foreign" CP/M disk types.
But you have to remember that when CP/M first came out, the de facto standard was 8" single-sided FM 77x26x128 format. That was the way the OEM kit was shipped along with any other system disks. It was DRI's standard distribution medium well into the 1980s. Gary Kildall has been reported as saying at one time that the 3740-type format was the only one "official" format that was recognized by DRI.
But you have to remember that when CP/M first came out, the de facto standard was 8" single-sided FM 77x26x128 format. That was the way the OEM kit was shipped along with any other system disks. It was DRI's standard distribution medium well into the 1980s. Gary Kildall has been reported as saying at one time that the 3740-type format was the only one "official" format that was recognized by DRI.
Rundel
New Member
A little late, I know, but I had a go at this. It works on my homebrew CP/M 2.2 system, but it would be interesting for someone to try it on "real" hardware.
https://github.com/rundel-tech/ZARC/tree/main/software/cpm/cpm_dev/fsck
Source code is included.
https://github.com/rundel-tech/ZARC/tree/main/software/cpm/cpm_dev/fsck
Source code is included.
Bruce Tomlin
Experienced Member
It makes a lot of assumptions from floppy-size versions of CP/M such as no more than 256 blocks per disk, and no more than 16 extents per file. Basically all it does is keep track of the owner of every block and reports when two files try to claim the same block.
Last edited:
Rundel
New Member
@alank2 good point. fsck now defaults to not scanning the entire surface. There is a command line option ("
/s") to enable it. Adding this option sent me down a rabbit hole related to how options are specified in CP/M. As a result, the option can be specified as "/s", "$s" or "[s]". "fsck" on its own issues a terse reminder of the syntax.There's no license associated with your project.
Rundel
New Member
GNU General Public License v3.0 added, which seems the best fit of the commonly available licenses.
Rundel
New Member
Thanks to Chris Radek, FSCK has now been tested on vintage hardware and not just my one-of-a-kind lockdown project. This is an Imsai, a Z80 S100 machine running CP/M 2.2 with an 8" single sided single density (standard IBM 3740 format) floppy. There were some issues, but these have been fixed with the help of the owner and we now have FSCK 1.2. See: https://github.com/rundel-tech/ZARC/tree/main/software/cpm/cpm_dev/fsck for details.