OSDev.org

Hello again,
I've been rewriting my FAT12 floppy disk drivers to support directories and disk changes.

I plan to detect disk changes by reading the serial number from the first sector of the disk and comparing it to the last one known. Would this work for all disks?

Also, I want to have a random serial number for my boot disk. I can't seem to find a way to do this since the parameters are statically compiled as part of the bootloader. Is there any to get NASM to embed a random data value?

incbin?

That's a great idea!
I could have the build script generate a four bytes of randomness under Linux using a disk dump from a virtual device like /dev/random then use 'incbin' to substitute the serial number in the assembly.
I will search the net for some random data generators for the other operating system my build scripts cover.

Thanks for your help.

Type 32 random ones and zeroes and a b.

Hi,

Prochamber wrote:I plan to detect disk changes by reading the serial number from the first sector of the disk and comparing it to the last one known. Would this work for all disks?

No - someone can copy a disk (including the first sector) using any OS and then change data on one of the copies.

Prochamber wrote:Also, I want to have a random serial number for my boot disk. I can't seem to find a way to do this since the parameters are statically compiled as part of the bootloader. Is there any to get NASM to embed a random data value?

Does it need to be random, or could it be "pseudo unique"? For example, you could probably just use the "__POSIX_TIME__" macro that's built into NASM.


Cheers,

Brendan

m12 wrote:Type 32 random ones and zeroes and a b.

No, that wouldn't work. It wouldn't be random for each disk generated.

Brendan wrote:

Prochamber wrote:I plan to detect disk changes by reading the serial number from the first sector of the disk and comparing it to the last one known. Would this work for all disks?

No - someone can copy a disk (including the first sector) using any OS and then change data on one of the copies.

I know in my OS I would randomize the serial number in a disk copy but I can't rely on every operating system doing this. The disk could just be copied as an image file anyway.
If not with a serial number, how can I detect a disk change? I have to know when to invalidate the subdirectory and cached content.
I looked at the disk change line through BIOS but it doesn't seem to be supported on all systems.

Brendan wrote:

Prochamber wrote:Also, I want to have a random serial number for my boot disk. I can't seem to find a way to do this since the parameters are statically compiled as part of the bootloader. Is there any to get NASM to embed a random data value?

Does it need to be random, or could it be "pseudo unique"? For example, you could probably just use the "__POSIX_TIME__" macro that's built into NASM.

That would probably be easier for my needs. According to the specification this macro should generate 4-bytes corresponding to the POSIX time.
Thanks for your help!

Hi,

Prochamber wrote:I know in my OS I would randomize the serial number in a disk copy but I can't rely on every operating system doing this. The disk could just be copied as an image file anyway.
If not with a serial number, how can I detect a disk change? I have to know when to invalidate the subdirectory and cached content.
I looked at the disk change line through BIOS but it doesn't seem to be supported on all systems.

The floppy hardware itself has a convenient "media changed" flag. There's 2 problems - some (very rare) hardware doesn't support the "media changed" flag, and a lot of BIOSs don't support the "disk changed" function correctly. To detect disk change reliably you have to stop using the BIOS. Then you could assume the hardware's "media changed" flag doesn't work until the first time you see it change (or perhaps use some sort of "disk_change_works = true" variable in your driver's configuration file or something).

Note: assuming the hardware's "media changed" flag doesn't work would mean invalidating the disk cache whenever the floppy motor is turned off; and possibly leaving the floppy motor on for longer to avoid invalidating the disk cache as often. This relies on the fact that users are reluctant to rip a disk out of a drive while it's spinning.


Cheers,

Brendan

Prochamber wrote:

m12 wrote:Type 32 random ones and zeroes and a b.

No, that wouldn't work. It wouldn't be random for each disk generated.

It was a joke.

Hi,

m12 wrote:

Prochamber wrote:

m12 wrote:Type 32 random ones and zeroes and a b.

No, that wouldn't work. It wouldn't be random for each disk generated.

It was a joke.

I think this belongs here (from http://xkcd.com/ ):



Cheers,

Brendan

Brendan wrote:I think this belongs here (from http://xkcd.com/ ):

lol! I've seen that one but still good for a laugh.

m12 wrote:

Prochamber wrote:

m12 wrote:Type 32 random ones and zeroes and a b.

No, that wouldn't work. It wouldn't be random for each disk generated.

It was a joke.

Ah sorry, good xkcd by Brendan thought, it's one of my favorites. Along with Genetic Algorithms and Networking.

Brendan wrote:The floppy hardware itself has a convenient "media changed" flag. There's 2 problems - some (very rare) hardware doesn't support the "media changed" flag, and a lot of BIOSs don't support the "disk changed" function correctly. To detect disk change reliably you have to stop using the BIOS. Then you could assume the hardware's "media changed" flag doesn't work until the first time you see it change (or perhaps use some sort of "disk_change_works = true" variable in your driver's configuration file or something).

Probably a good point. For now I'll use detection through BIOS with the serial number as a fallback. Later after my file system code is finished and working I'll try to write some floppy disk drivers. The specification seems quite complex and I'll need to handle all three modes to work on real hardware and on emulators.

Prochamber wrote:If not with a serial number, how can I detect a disk change? I have to know when to invalidate the subdirectory and cached content.

On floppy disks your "total logical sectors" in the BPB is a word at offset 0x13 from the start of the boot sector. Since DOS 3.31, however, the BPB has also had a dword "total logical sectors" entry at offset 0x20 to be used if the total logical sectors word is set to 0 (meaning "greater than 65535 sectors"). On a floppy you're going to have a maximum of somewhere around 3400 sectors (depends on how the floppy is formatted: see DMF), meaning that the dword at 0x20 is potentially usable for writing a timestamp every time the drive is accessed and then comparing it to the "last access" timestamp in memory before writing the new one.

Of course this may not be viable in all circumstances. What if a floppy is write-protected? What is the OS tramples the dword at 0x20 even if it doesn't need to?

Just throwing ideas out there.

Hi,

Blacklight wrote:Of course this may not be viable in all circumstances. What if a floppy is write-protected? What is the OS tramples the dword at 0x20 even if it doesn't need to?

Just throwing ideas out there.

I was thinking the disk's serial number would be written when the disk is formatted and then not touched after. Regardless of how the serial number is used, you could take the floppy out of one computer and put it in a Windows/Linux computer and modify the contents (e.g. create/delete files or directories), then put it back in the first computer (which doesn't realise the disk has been "changed") and end up with a corrupted file system because of stale data in the disk cache.

This got me thinking of alternative ways to handle floppy. What I came up with was to have a catalogue of floppy disk images on your hard drive; where software (file systems, etc) only ever use the images on the hard drive. Then you'd have an "import from floppy" feature that reads the entire floppy, checks if the floppy is already in the catalogue on hard drive, and adds the entire floppy to the catalogue if necessary. You'd still want to use some sort of floppy serial number, but it'd be used like a hash key so that when a floppy is imported you only need to check images that have the same serial number/hash key (and don't need to check all images) to determine if the same floppy image is already in the catalogue. You'd also have an "export to floppy" feature to write a floppy image from the catalogue onto a floppy disk (where "writing" might mean formatting the floppy to suit the image's geometry, then writing the data, then verifying).

In this case, because you'd only ever be reading/writing an entire floppy at a time, you don't need to worry about caching floppy disk sectors (in the floppy driver) and don't need any "floppy disk media changed" notification.


Cheers,

Brendan

This is indeed similar to how mac (or toast) handle CDR, with extra category feature.

Based on what I've seen, I've constructed a list of options:

1) Disk Change Line
Check the disk change line (or through BIOS) to see if the floppy has been changed.

• Pro: Simple and doesn't require any extra disk activity.
• Con: Change line is not supported on some floppy disk controllers or buggy BIOSes.

2) Disk Serial Numbers
Read the BPB and compare the serial number to the last known.

• Pro: Should work on all floppy disks and floppy disk drives.
• Con: Serial number may not be unique for all disks. i.e. copied disks or if the field is formatted with zeros.

3) Disk Stamping
Write a random number onto the disk and registers a disk change when this number changes, then write a new number.

• Pro: Guaranteed tracking on all disks.
• Con: Will not work on read-only disks.

I think the best method is a mixture of these.
If the disk change line is supported then the driver will use option one.
If the change line is not supported then the driver will attempt to write a random number to the serial field.
If the write fails with a write protection error then the driver will use option two, otherwise the driver will use option three.