woodside@ttidca.TTI.COM (George Woodside) (03/31/88)
...[edited quite a bit]... >I tried BOOTSEC on a freshly formatted disk, and found a serial number >that changed after I formatted the disk again. Then I tried PENICILN >on the same disk. I used the command > > peniciln -m a > >to write an MS-DOS compatible boot sector. I noticed that the serial >number was > > 3354162, > >and I thought that I had seen that one before. Well, almost. What I >was remembering was the number produced by IBMFMT. The program IBMFMT, >posted to this net some time ago, always gives the serial number > > 3354163. > >What does MS-DOS do about serial numbers. > >Does it matter to DOS or MS-DOS if they are all the same? The formatting programs for the ST usually generate a random serial number for the disk when they format it. There is a way to assign a serial number to a disk, but I haven't seen any formatters that offer that function. MS-DOS doesn't use serial numbers. But it does write an operating system ID on the disk. A typical ID might read "IBM 3.2". There are two spaces between the "IBM" and the "3.2". This ID is in bytes 3 - 10 of the boot sector. Bytes 8 - 10 of the boot sector are used by TOS/GEMDOS to store the serial number. So, any disk with "3.2" in bytes 8, 9 and 10 will appear to have the same serial number to GEMDOS. Any disk with "3.3" will also appear to be the same, and look like the serial number is one more than those with "3.2". >What "harm" will come to TOS users of several disks with > the same serial number? Potential disaster. GEMDOS (or TOS, whichever you prefer) uses the drive's write protect sensor to detect when a disk has been removed from the drive. The write protect sensor is a small light emitting diode, and a light sensing device. The disk passes between them. So, when you insert or remove a disk, there will be times when the body of the disk is between the light and the sensor, and other times when the space is open. That causes the light sensor to not see, then see, through the space. The drive signals the write protect status to the ST. The ST sees things change, and notes that the disk may have been changed. The next time you access that drive, GEMDOS reads the serial number to see if the disk really did change, or the same one is still there. Depending on exactly what the system was doing when the change was noted, different things may happen. I'm not an expert on all the possibilities, but if GEMDOS thinks that the same disk is back, while it is really a different disk with the same serial number, you can get a destroyed disk. GEMDOS will not have erased all the buffers, and may re-write things like the directory or FAT from buffers containing data from the first disk, onto the second one. > > Under GULAM, CHKFMT prints three tracks and exits with an error code. > Is there something wrong with my copy? > The technical term for this is "BLUNDER". I forgot to clear the return value when no error occurred. I don't use GULAM, so I didn't realize this was happening until now. CHKFMT is supposed to read eight disk surfaces and report the sector sequences on them. That will be tracks 0 - 7 on a single sided disk, and 0 - 3 on double sided disks. That should be enough sequential track images to illustrate the formatting pattern. There's probably nothing wrong with your copy. I generally post source code for things, but this program contains routines that could be easily modified for piracy or virus generating, so I didn't think it was too good an idea to unleash them. -- *George R. Woodside - Citicorp/TTI - Santa Monica, CA *Path: ..!{trwrb|philabs|csun|psivax}!ttidca!woodside