I've just been bitten by this very old bug so I'm resubmitting it as I can't see any old report (probably not sent to Debian) $ mformat r: -t 80 -h 2 -s 18 -c 4 -r 1 $ minfo r: ... mformat command line: mformat -t 80 -h 2 -s 18 r: ... cluster size: 1 sectors ... max available root directory slots: 224 ... $ Mformat totally ignores the -c, -r and other configuration options for any floppy or image that looks more or less like a 'standard' floppy. That mformat command line should give a standard DOS floppy with 2k clusters and 1436k free, this is more free space than is possible on a minixfs floppy and so is purrfect for storing a few zips. If the floppy is a 1772k image everything works properly: $ mformat r: -t 80 -h 2 -s 21 -c 4 -r 1 $ minfo r: ... cluster size: 4 sectors ... max available root directory slots: 16 ... sectors per fat: 3 ... $ The floppy has 1,716,224 out of 1,720,320 bytes free (4k overhead). Also mformat seems to have lost it's option for specifing the number of FATs on the filesystem, if I use mkdosfs the following command line gives 2k clusters, 1436k free and 64 root directory entries. $ mkdosfs -s 4 -r 64 -F 12 -f 1 /tmp/ramdisk 1440 For mformat even using the -k option destroys the existing boot sector information.
This bug needs some more information, could you give me more specific information so that I could track this down ? regards, junichi
This bug needs some more information, could you give me more specific information so that I could track this down ? regards, junichi
What information specifically ? I've appended a full script of a simple session below. mformat manual: If I add the "-c 4" option mformat should set the cluster size to 2k If I add the "-r 1" option mformat should set the root directory to one sector. Reiterate: If the size of the floppy is not a standard one (eg it is 79/2/18) then these arguments are honoured. If the size of the floppy is a standard one (eg: 80/2/18) mformat ignores these flags (without error) and always does what it thinks is right. (Just like a windows program) Workaround: To get the format I want I have to use mkdosfs. (eg: mkdosfs -s 4 -r 16 /tmp/ramdisk 1440 )
So, your bugreport is telling me that mtools is being compatible with MSDOS behavior ? regards, junichi
That's an interesting way of interpreting what I said. What I mean is that mformat is ignoring the flags: -c -r -k It gives no errors and there is no indication that it is failing to act on these options, infact it gives the normal unix indication that it has done _exactly_ what I've asked for.
Robert de Bath <robert$@mayday.cix.co.uk> cum veritate scripsit: Well, yes. The code gave me an impression that it was done on purpose because with such geometry, MS-DOS will be fooled to think that they have some predefined format, and it is done for compatibility. regards, junichi
that they have to obey the disk layout fields from CP/M and the _only_ time that any of the DOS varients (including eg, the Atari-ST) have ever had any problems is when the fields contradict each other. The main example of this is if the size of the FAT needed by the total number of clusters is different from the size of the FAT specified on disk. (This example actually caused problems with one of the standard format sizes on the Atari-ST - the ST being definitly in the wrong) And anyway, since when is a UNIX tool supposed to stop you shooting yourself in the foot? There's never any 'Are you sure (N/y)' and a true unix tool will never 'adjust' anything you tell it; the programmer isn't psychic and so cannot ever say what the user actually wants only what they have said they want and if that's _definity_ wrong all you can do is stop and say so. FX: ... went off and looked at the source ... Phew! what a mess! Talk about feeping creaturitus. I see what you mean though about that 'old_dos' array, but I suspect the 'compatibility' it's going for is with the MS-DOS format _command_. Nevertheless I wouldn't like to try to maintain anything resembling a feature patch against this source so I'll go away and see what they say in the mtools mailing list. Thankyou for your time.
Robert de Bath <robert$@mayday.cix.co.uk> cum veritate scripsit: Yes... I've read the source, looked at your bug report, and sighed... Well, it seems like that they want to emulate the MS-DOS tools in the truest sense... No problem, junichi