anderson@vms.macc.wisc.edu (Jess Anderson) (12/30/89)
In my office machine (386), I have 1.2 and 1.44 mb floppy drives. Vanilla 1.3 runs on this machine. On a lark, I tired to back up from /at0 to /at1. Also tried making an empty file system on /at1. Well, mkfs won't accept 1440 blocks on /dev/at1, which didn't surprise me that much. It will accept 1200, though, and in any case a cp /dev/at0 /dev/at1 will make a backup disk on the 3.5" drive. That sparked the interest of a colleague who has a PS/2 model 50Z with a 3.5" drive A and a hard disk. I was a bit astonished that the boot disk seemed to be acceptable, at least I got the boot menu. But it would not read the root file system after the = entry (reads /dev/fd0 forever). But I also seem to remember that model 50 was not yet on the compatibility list. Anyone know the facts here? ==Jess Anderson===Academic Computing Center=====Univ. Wisconsin-Madison===== | Work: Rm. 2160, 1210 West Dayton St., Madison WI 53706, Ph. 608/263-6988 | | Home: 2838 Stevens St., 53705, 608/238-4833 Bitnet: anderson@wiscmacc | ==Internet: anderson@macc.wisc.edu====UUCP:{}!uwvax!macc.wisc.edu!anderson==
overby@plains.UUCP (Glen Overby) (12/30/89)
In article <2879@dogie.macc.wisc.edu> anderson@vms.macc.wisc.edu (Jess Anderson) writes: >Well, mkfs won't accept 1440 blocks on /dev/at1, which >didn't surprise me that much. It will accept 1200, though, Minix block devices have a size associated with them. fd0 and fd1 are 360K while at0 and at1 are 1.2M. You will need to make a new device file with the same major/minor numbers and a larger size (I don't believe mknod allows you to specify a size; just when the disk is make with mkfs). You'll probably need "ps_wini" and maybe a ps/2 definition in include/minix/config.h to get the ps/2 to go the rest of the way. -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) ncoverby@ndsuvax, overby@plains (Bitnet)
abrams@cs.columbia.edu (Steven Abrams) (12/31/89)
In <2879@dogie.macc.wisc.edu> Jess Anderson writes:
[...Stuff about 3.5" drives deleted...]
That sparked the interest of a colleague who has a PS/2
model 50Z with a 3.5" drive A and a hard disk. I was a
bit astonished that the boot disk seemed to be acceptable,
at least I got the boot menu. But it would not read the
root file system after the = entry (reads /dev/fd0 forever).
But I also seem to remember that model 50 was not yet on
the compatibility list. Anyone know the facts here?
I just TA'ed a class using Minix, and one of the students had a Model
50Z. Plain vanilla 1.3 would not work on that machine. However,
1.4.2, which ast sent me, did work. So did 1.4.5, which I was
beta-testing. I assume that 1.5.0 will work, but I haven't unpacked
my stuff (nor will I 'til I get back to school after break).
~~Steve
--
/*************************************************
*
*Steven Abrams abrams@cs.columbia.edu
*
**************************************************/
#include <std/dumquote.h>
#include <std/disclaimer.h>ast@cs.vu.nl (Andy Tanenbaum) (01/01/90)
In article <3060@plains.UUCP> overby@plains.nodak.edu (Glen Overby) writes: >I don't believe mknod allows >you to specify a size; just when the disk is make with mkfs. I know. One can patch it with de, but admittedly a better scheme is needed. You can use mkfs, but then you get size 0, which works for most things, but not copying the device since it doesn't know when to stop. Andy Tanenbaum (ast@cs.vu.nl)
paula@bcsaic.UUCP (Paul Allen) (01/03/90)
In article <5032@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <3060@plains.UUCP> overby@plains.nodak.edu (Glen Overby) writes: >>I don't believe mknod allows >>you to specify a size; just when the disk is make with mkfs. > >I know. One can patch it with de, but admittedly a better scheme is needed. >You can use mkfs, but then you get size 0, which works for most things, >but not copying the device since it doesn't know when to stop. I've worked up a scheme that might be better. It's not complete, but I've only invested about 6 hours so far. I'll start with a bit of motivation and then describe what I've done. I got tired of the glacial speed of the floppy driver under 1.3 and decided to add interleaving. But since all my existing floppies were written by the old driver, needed to be able to deal with both interleaved and non-interleaved floppies. Also, in order to do interleaving, you need to know the sectors per track, which depends on the drive/media combination. But the driver tries different combinations if if gets errors. It seems like the driver ought to return EOF (or something) if you try to access beyond the end of the media, but you can't know what type of media you've got until you have a successful transfer, which you can't have if the requested block is off the end of the disk! Aaaagh! I've attacked my perceived problems in the 1.3 floppy driver with the following scheme: - The minor device number encodes the drive number, whether to use interleaving, and the drive/media combination. Given the drive/media code, one can look up stuff like the sectors per track and blocks per disk. - The 'd' (drive/media combination code) variable in floppy.c gets set by shifting and masking the minor device number. - The logic to try different values of 'd' is intact for the odd situation (like booting :-) ) when the requested minor device doesn't match the actual drive and media. I'd like to remove this and let an error just be an error. - A new subroutine fl_il() maps logical block numbers into physical block numbers and knows how to do 2:1 interleaving on 9- and 15-sector disks. I don't have any 3" drives, and haven't implemented 18-sector disk interleaving. - The driver now returns EOF when the requested logical block is beyond the end of the media as specified by the minor device number. - There are now quite a few floppy devices in /dev, and their names reflect the specific configuration encoded in their minor device numbers. The device special files were created with mknod, and do not contain sizes. I'm thinking about fixing the kernel so that the default minor device for floppy drive 0 specifies a 1.2M disk in a 1.2M drive without interleaving (my standard setup). It should probably be configurable via the makefile, or perhaps the default should be set based on what's in the drive at boot time. Anybody have any thoughts? The good news is that writing tarfiles to a 2:1 interleaved 1.2M floppy is now twice as fast as with the old driver and reading tarfiles from the same floppy is four times as fast as before. The bad news is that having the driver return EOF at the end of the volume doesn't have the same effect as putting the size in the inode. For example, GNU tar complains about a short write and aborts at the end of the first volume when writing a multi-volume archive. With the old driver and the old /dev/at0, gtar simply asked for the next volume to be mounted. I've been poking around trying to find the place in the code that uses the inode size field to detect end-of-device, but haven't found it yet. Has anybody run down this line of inquiry before? Does what I've done make any kind of sense? Is this all moot because the 1.5 floppy is 10 times faster than 1.3? (The reason I'm messing with 1.3 is that I need to back up my disk before I let 1.5 touch it. The thought of tar'ing my current 23M of Minix data at 4-5 minutes per floppy is real discouraging!) Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
Peter_Van_Epp@cc.sfu.ca (01/04/90)
>From: paula@BCSAIC.UUCP >Subject: Re: 3.5" disks, PS/2 model 50Z ... >I got tired of the glacial speed of the floppy driver under 1.3 and >decided to add interleaving. But since all my existing floppies were >written by the old driver, needed to be able to deal with both >interleaved and non-interleaved floppies. Also, in order to do >interleaving, you need to know the sectors per track, which depends on >the drive/media combination. But the driver tries different >combinations if if gets errors. It seems like the driver ought to >return EOF (or something) if you try to access beyond the end of the >media, but you can't know what type of media you've got until you have >a successful transfer, which you can't have if the requested block is >off the end of the disk! Aaaagh! I am also having problems with 1.44m disks on a PS/2 mod 55, I have modified bootblok.s to boot from a 1.44M (and will post it after I test it on all possible combintions of disks), I have something semi working with floppy.c modified to only recognize 1.44m disks but mkfs can't make a root file system that 1.5.0 will accept (the one I use was built on an XT on 360k floppy and moved via DOS to a 1.44m), I am still working on why this is. In any case floppy.c seems to attack the density problem all wrong, I would rather see it do the same as bootblok.s to determine what kind of floppy you have got: when the drive is reset because of an error, or at initalization, read track 0 sector 18 to see if it is 1.44m sector 15 for 1.2m etc (see table below). This data would then be saved and used every time a floppy is accessed, and if the disk is changed then and error should occur and the reset should reset the disk type (not foolproof but seems better than current!). Table of disk characteristics 1.44m 3.5" 80 tracks 18 sectors/track(read track 0 sector 18) 1.2m 5.24 40 tracks 15 sectors/track(read track 0 sector 15) 720k 3.5" 9 sectors/track 80 tracks (read track > 40 sector 1) 360k 5.25 40 tracks 9 sectors/track (if all the others fail this must be it!).
Peter_Van_Epp@cc.sfu.ca (01/04/90)
> From: dlawyer%balboa.eng.uci.edu@orion.oac.uci.edu > In article <7317@nigel.udel.EDU> you write: > >1.2m 5.24 40 tracks 15 sectors/track(read track 0 sector 15) > This is 80 tracks. It's called 5 1/4 inch which is 5.25 ". What can I say? A combination of fat fingers (5.24 instead of 5.25) and failing memory (a 1.2M 5.25 disk is in fact 80 tracks), however the tests for disk type are indeed correct (ie. if you can't read track 0 sector 18, but can read track 0 sector 15 then this is probably a 1.2M 5.25 AT floppy)! Thanks for pointing this out!
gwr@linus.UUCP (Gordon W. Ross) (01/06/90)
In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: [ Much deleted for brevity ] > I got tired of the glacial speed of the floppy driver under 1.3 and > decided to add interleaving. [ discusses problems identifying media types ] > I've attacked my perceived problems in the 1.3 floppy driver with the > following scheme: > > - The minor device number encodes the drive number, whether to > use interleaving, and the drive/media combination. Given the > drive/media code, one can look up stuff like the sectors per > track and blocks per disk. > > - The 'd' (drive/media combination code) variable in floppy.c > gets set by shifting and masking the minor device number. > > - The logic to try different values of 'd' is intact for the > odd situation (like booting :-) ) when the requested minor > device doesn't match the actual drive and media. I'd like > to remove this and let an error just be an error. A good way to handle this is to add another minor device type which is a "media sensitive" device useful for reading and writing formatted diskettes. The other minor devices corresponding to particular diskette formats would be useful with a diskette formatting program. > - A new subroutine fl_il() maps logical block numbers into > physical block numbers and knows how to do 2:1 interleaving > on 9- and 15-sector disks. I don't have any 3" drives, and > haven't implemented 18-sector disk interleaving. Sector interleaving, as I understand it, should not necessitate any change in the mapping of logical-to-physical disk blocks. When the floppy disk controller (FDC) is asked to read or write a sector with a particular ID the FDC waits for the sector with that ID to rotate under the read/write head and then carries out its work. The physical positioning of these sectors and the order of sector ID marks on the track depends only on the interleave table used when the the disk was formatted. With this understood, I think it would be a big mistake to re-map the order of logical blocks to something other than sequential sector ID numbers. Sector interleave should be the concern of the formatter. > - The driver now returns EOF when the requested logical block > is beyond the end of the media as specified by the minor > device number. [ see below ] > > - There are now quite a few floppy devices in /dev, and their > names reflect the specific configuration encoded in their > minor device numbers. The device special files were created > with mknod, and do not contain sizes. > > I'm thinking about fixing the kernel so that the default minor device > for floppy drive 0 specifies a 1.2M disk in a 1.2M drive without > interleaving (my standard setup). It should probably be configurable > via the makefile, or perhaps the default should be set based on what's > in the drive at boot time. Anybody have any thoughts? Yes. Boot (and otherwise read) from the "media sensitive" device. > The bad news is that having the driver return EOF at the end of the > volume doesn't have the same effect as putting the size in the inode. > For example, GNU tar complains about a short write and aborts at the end > of the first volume when writing a multi-volume archive. With the old > driver and the old /dev/at0, gtar simply asked for the next volume to be > mounted. Actually, the return value to use is not so simple. After studying our Sun, Sys V/386, and GNU tar (by John Gillmore) it seems that the following behavior is expected of an mtio(4) compatible device: + Sequential reads past the end of the device should return zero. (maybe EOF on subsequent reads?) + Seek past the end should return error, EIO (I/O error). + Sequential writes past the end of the device should return error, ENOSPC (No space). > > I've been poking around trying to find the place in the code that uses > the inode size field to detect end-of-device, but haven't found it yet. Isn't the device size check done in kernel/floppy.c: do_rdwt() ? > Paul L. Allen | pallen@atc.boeing.com > Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen -- Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr Burlington Road, Bedford, MA 01730 (617) 271-3205 -- Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org The MITRE Corporation UUCP: {decvax,philabs}!linus!gwr Burlington Road, Bedford, MA 01730 (617) 271-3205
Peter_Van_Epp@cc.sfu.ca (01/06/90)
GWR@LINUS.UUCP writes: >In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: > >A good way to handle this is to add another minor device type which is > >a "media sensitive" device useful for reading and writing formatted >diskettes. The other minor devices corresponding to particular >diskette formats would be useful with a diskette formatting program. > Another suggestion (and the rational behind it!): cause build bootblok.s actually) to put a media identifier byte ala DOS into the bootblok on a boot disk (for bootblok) and via mkfs (and/or the format program when one is written) into the currently unused boot block on all floppy media. Why do this? It makes life easy for both bootblok.s and floppy.c, I have modified bootblok.s to boot from 1.44m disks and as part of the clean up added a table for 720k 3.5in disks (rather than look in a prom location that may or may not be correct for any given machine!), however bootblok grinds my 360k floppy head into the stop trying to seek past track 40 to see if this is a 720k 3.5in drive. Floppy.c does a somewhat similar operation trying to figure out what size the floppy is (and is complicated by such things as a 360k disk in a 1.2m drive or a 720k disk in a 1.44m drive which the minor device numbers don't address!). Given that all floppy media have a type byte (lets use the same ones as DOS! I have some and can get (ie. have acces to disks) for the ones I don't (720k and 1.44m)), in the boot sector both floppy.c and bootblok.s can determine what type of diskette is in the drive by reading track 0 head 0 sector 1 (an operation valid on all disk types and we are on track 0 during a reset anyway!). I suspect that this will speed up floppy.c (the code suggests a speed improvment can be made by restricting the type of drive to 3.5 or 5.25) and yet it is still universal so you can boot and read with the same code from either 3.5 or 5.25 disks and as a bonus, I hope it will with the problems reading and writing 1.44m disks.
paula@bcsaic.UUCP (Paul Allen) (01/09/90)
In article <85654@linus.UUCP> gwr@linus.mitre.org writes: -In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: -[ Much deleted for brevity ] - -> I got tired of the glacial speed of the floppy driver under 1.3 and -> decided to add interleaving. - -[ discusses problems identifying media types ] - -> I've attacked my perceived problems in the 1.3 floppy driver with the -> following scheme: -> -> - The minor device number encodes the drive number, whether to -> use interleaving, and the drive/media combination. Given the -> drive/media code, one can look up stuff like the sectors per -> track and blocks per disk. -> -> - The 'd' (drive/media combination code) variable in floppy.c -> gets set by shifting and masking the minor device number. -> -> - The logic to try different values of 'd' is intact for the -> odd situation (like booting :-) ) when the requested minor -> device doesn't match the actual drive and media. I'd like -> to remove this and let an error just be an error. - -A good way to handle this is to add another minor device type which is -a "media sensitive" device useful for reading and writing formatted -diskettes. The other minor devices corresponding to particular -diskette formats would be useful with a diskette formatting program. Thanks, that's a good idea. And since you jogged my thinking cap, it occurs to me that the media type detection logic ought to be in the dev_open routine for floppy.c. Currently, both the dev_open and dev_close routines for major device 2 are null. If the floppy's dev_open and dev_close sent messages to the fs informing it of changes in the floppy's status, the 'size in the inode' mess would not be necessary. It would also not be necessary to read or write anything other than the 'media sensitive' device, as Gordon suggests. Now, will some wizard point out what's wrong with this? -> - A new subroutine fl_il() maps logical block numbers into -> physical block numbers and knows how to do 2:1 interleaving -> on 9- and 15-sector disks. I don't have any 3" drives, and -> haven't implemented 18-sector disk interleaving. - -Sector interleaving, as I understand it, should not necessitate any -change in the mapping of logical-to-physical disk blocks. [nice description of physical interleaving deleted] -With this understood, I think it would be a big mistake to re-map the -order of logical blocks to something other than sequential sector ID -numbers. Sector interleave should be the concern of the formatter. In general, I agree. However, interleaving via software is much easier to implement and accomplishes the identical result. (I only added about 20 lines to floppy.c and it worked first time.) One catch is that you need to know whether any given floppy was written with interleaving in order to read it. I consider this a small price, since essentially all of my floppies will be written interleaved from now on. Now, if someone wants to write a floppy formatting program for PC Minix, I would abandon my software interleaving scheme in a minute! Since the new /dev/port interface may not be fast enough for formatting floppies, the actual code to diddle the fdc may need to be in the kernel. That implies either a new system call or some ioctl() interface or... -> - The driver now returns EOF when the requested logical block -> is beyond the end of the media as specified by the minor -> device number. - [ see below ] -> -> - There are now quite a few floppy devices in /dev, and their -> names reflect the specific configuration encoded in their -> minor device numbers. The device special files were created -> with mknod, and do not contain sizes. -> -> I'm thinking about fixing the kernel so that the default minor device -> for floppy drive 0 specifies a 1.2M disk in a 1.2M drive without -> interleaving (my standard setup). It should probably be configurable -> via the makefile, or perhaps the default should be set based on what's -> in the drive at boot time. Anybody have any thoughts? - -Yes. Boot (and otherwise read) from the "media sensitive" device. - -> The bad news is that having the driver return EOF at the end of the -> volume doesn't have the same effect as putting the size in the inode. -> For example, GNU tar complains about a short write and aborts at the end -> of the first volume when writing a multi-volume archive. With the old -> driver and the old /dev/at0, gtar simply asked for the next volume to be -> mounted. - -Actually, the return value to use is not so simple. After studying -our Sun, Sys V/386, and GNU tar (by John Gillmore) it seems that -the following behavior is expected of an mtio(4) compatible device: - -+ Sequential reads past the end of the device should - return zero. (maybe EOF on subsequent reads?) - -+ Seek past the end should return error, EIO (I/O error). - -+ Sequential writes past the end of the device should - return error, ENOSPC (No space). If you ask Minix 1.3 (protected mode version) to write past the end of /dev/at0, the write() returns 0 and errno is also 0. It seems to me that the proper value would be ENXIO (no such device or address). The man page on my Sun documents ENXIO as including access beyond the end of a device. -> -> I've been poking around trying to find the place in the code that uses -> the inode size field to detect end-of-device, but haven't found it yet. - -Isn't the device size check done in kernel/floppy.c: do_rdwt() ? On a read, you can wait until the request gets down into the driver to check for access off the end of the media. On a write, however, the system call completes when the block gets put in the block cache. Therefore, the fs needs some way to detect end-of-media before handing requests off to the block cache. Putting the device size in the inode is one way. Having the floppy dev_open routine inform the fs about the current device size might be another. (If I've got things wrong here, I trust someone will set me straight.) I'll try some experiments tonight and post if I learn anything. -> Paul L. Allen | pallen@atc.boeing.com -Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
paula@bcsaic.UUCP (Paul Allen) (01/10/90)
In article <7546@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes: >GWR@LINUS.UUCP writes: >>In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: >>> [I suggested encoding the floppy drive/media combination using three >>> bits in the minor device number, but noted potential problems at >>> boot time.] >>A good way to handle this is to add another minor device type which is > >>a "media sensitive" device useful for reading and writing formatted >>diskettes. The other minor devices corresponding to particular >>diskette formats would be useful with a diskette formatting program. >> >Another suggestion (and the rational behind it!): cause build >bootblok.s actually) to put a media identifier byte ala DOS into >the bootblok on a boot disk (for bootblok) and via mkfs (and/or >the format program when one is written) into the currently unused >boot block on all floppy media. This is fine for diskettes with file systems on them, but doesn't do anything for the case where I want to write a tarfile to /dev/at0. All floppy media do not have boot blocks. My suggestion of putting the drive/media type code in the minor device number would work, but it requires the user to specify the proper device name. gwr@linus.uucp suggested adding a media-sensitive minor device which would use a heuristic to figure out the drive/media code at run-time. In a response to gwr, I suggested that perhaps the figuring-out of media type should be done in the dev_open() routine for the floppy driver and a message could be sent to the fs informing it of the current size of the floppy device. The fs needs to know the size of the device in order to do the right thing when access beyond the end of a floppy is attempted. Currently, the floppy has a null dev_open() routine. The more I think about this, the more I like it, but then I'm not a Unix internals wizard. I would appreciate comments. (Perhaps my minor-device scheme is only necessary for formatting, as gwr suggests.) In the meantime, I've got some experiments in mind and will post more when I learn something. Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
Peter_Van_Epp@cc.sfu.ca (01/11/90)
>From: paula@BCSAIC.UUCP >In article <7546@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes: >.. stuff deleted > >This is fine for diskettes with file systems on them, but doesn't do >anything for the case where I want to write a tarfile to /dev/at0. >All floppy media do not have boot blocks. > At present true, but the reason is that MKFS specifically overwrites the bootblock that MSDOS Format put there (with the device parameters) with a block of 0's. If MKFS is stopped from overwriting at least the device parameters, any disks parameters can be read from floppy.c. Since I have finished and posted my mods that do a similar thing for boot block, this is probably my 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 and 4.01 at least, because I have made bootable disks on all 4 media types formated with the DOS format command. I would be interested to know of any format program (Norton? are there other format programs?) that don't do this. >------------------------------------------------------------------------ >Paul L. Allen | pallen@atc.boeing.com >Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen Peter Van Epp
Peter_Van_Epp@cc.sfu.ca (01/12/90)
0/90, 32 >>From: paula@BCSAIC.UUCP >>In article <7546@nigel.udel.EDU> Peter_Van_Epp@cc.sfu.ca writes: >>.. stuff deleted >> >>This is fine for diskettes with file systems on them, but doesn't do >>anything for the case where I want to write a tarfile to /dev/at0. >>All floppy media do not have boot blocks. >> > At present true, but the reason is that MKFS specifically > overwrites the bootblock that MSDOS Format put there (with the > device parameters) with a block of 0's. If MKFS is stopped from > overwriting at least the device parameters, any disks parameters > can be read from floppy.c. Since I have finished and posted my > mods that do a similar thing for boot block, this is probably my > 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 > and 4.01 at least, because I have made bootable disks on all 4 > media types formated with the DOS format command. I would be interested > to know of any format program (Norton? are there other format programs?) > that don't do this. > >>------------------------------------------------------------------------ >>Paul L. Allen | pallen@atc.boeing.com >>Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen > >Peter Van Epp oops! A clear case of engaging fingers before brain! while the stuff about format is correct, as Paul pointed out (and which I finally understood) any program (such as tar ,ar and probably others) which choose to write to "file" /dev/fdx is in fact going to overwrite the data in the boot sector of the floppy, and since Minix needs to be able to write the boot sector to make boot disks I can't see any clean way to make this idea work. Back to the drawing boards for me!