lloyd@comp.vuw.ac.nz (Lloyd Parkes) (01/15/90)
In article <7866@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes:
next project. Re reading this I just noticed the part about without
a file system, assuming that the disk has been formatted by MSDOS
format (and I suspect, for DOS to read it but I haven't tried!)
there is a "boot block" (without boot code but with the disk parms)
on Track 0 sector 1 head 0 of the disk (my boot mods depend on
this fact!), so the block is there unless the disk has been run
through mkfs as noted above. This is true of Format from PCDOS 3.2
No, the DOS boot block will be overwritten by any use of
/dev/[at|fd]0, especially as a tar device. I have ~200 floppy disks,
and only two of them have Minix file systems on them. The others
either have DOS or are tar backups. There is definately no boot block
on a tar volume. This means that the driver must count, both the
number of sectors, and the number of tracks, preferably independently.
This would allow 800K low density disks in an AT drive for instance
(very useful under DOS these).
Also the 1.2M drive has the ability to detect a disk change, I don't
know if the 3.5" drives have this ability, or if Minix uses it, or
even how useful it would be in Minix.
The problem of finding out the geometry of a disk with no file system
on it is very hard (if you don't want to thrash the drive). One
solution, might be start the sector numbering (on track 0 anyway) from
some number other than zero. Different start numbers would indicate
different disk geometries, and you would avoid those deadly seek to
track 79 :-) This of course raises other problems.
Lloyd
--
------------------------------------------------------------------------
Lloyd | lloyd@comp.vuw.ac.nz | "... I can gleek upon occasion." -
Parkes | ...!uunet!vuwcomp!lloyd | Nick Bottom
------------------------------------------------------------------------hbetel@watserv1.waterloo.edu (Heather) (01/16/90)
What sort of header does a tar file have? Do we want to maintain compatability with other tar programs? If this is not important, there is an easy solution to the bootblock problem: make the tar header look like a bootblock. I don't have the bootblock structure in front of me, but it seems to me that we could put in all the important stuff, like disk size/geometry, any flags the rom bootstrap expects to see, and the rest holds tar information (whatever that happens to be). This means that in a 360k disk, the first 512 bytes are necessarily wasted, but I think It is worth it.