Extensible format submenu

I’m sure this has been suggested before, but anyway…

The ‘Format’ submenu, on drive icons, is now completely obsolete. All it offers are a selection of floppy disc formats (unlikely on the Iyonix, impossible on the BeagleBoard), and even more obsolete DOS and Atari formats.

This is also an excellent opportunity to make SCSIForm and HForm more user-friendly.

How about revamping the submenu in a similar fashion to what Acorn did to Configure a decade ago?

Instead of a list of hard-coded defaults, devise an API which allows any given module (or possibly executable) to add itself to the list of formatters known by any given filing system. (The existing formatters, if necessary, could be converted to this new API.)

So, for example (I’m not entirely sure what the distinction is at a low level, but I know I have SCSI::4 and ADFS::4), SCSIForm and HForm wouldn’t appear on the same list.

The ‘Formatting’ status window could also be made open to external applications (a la Free/Filer Action), if it isn’t already.

The application I’m principally thinking of is Fat32Format, as an up-to-date replacement for the obsolete DOS options in the case of removable devices (e.g. USB sticks).

While we’re at it, a cut-down version of SCSIForm should probably be included in ROM (and made available on the list) to make BeagleBoard setup less scary. (I’ve seen the BASIC code, and an assembler version should be pretty tiny.)

You should consult service call &6A (filer enumerate formats) and all your wishes will come true.

That’s not useful when the format submenu is greyed out in the first place, i.e. for every type of device except floppy discs.

I also don’t think a single-tasking BASIC program is an appropriate way of formatting a hard disc, especially when it has an entire useless menu begging for the job.

The hard-coded defaults of 1.6MB etc. would obviously be worthless, hence the need for different devices to report different possible formats (something else the service won’t do).

I also don’t think a single-tasking BASIC program is an appropriate way of formatting a hard disc, especially when it has an entire useless menu begging for the job.

Surely the point of a single-tasking programme is to ensure that nothing else can even attempt to access the device while it’s being formatted? How would you ensure that in a multi-tasking environment?

It would be very nice for all the relevant formatting options to be called from that menu. (However it is achieved).

It would also be good for a basic formatter to be in ROM. (And ultimately a package manager, so all you need is the rom and a net connection).

However, I don’t think it would be a good idea to change the current formatter until we have partition support. Ultimately it would be nice to have something like GParted. (Which would presumably switch to single tasking only when it was applying any changes.)

EDIT: But it would be nice to update it.

How would you ensure that in a multi-tasking environment?

In exactly the same way as the current floppy formatter ensures it.

Another irritation is that with the Format menu greyed out you cannot view the current format of the drive, making it harder to work out whether it’s a Filecore format, FAT12, FAT16 etc.

Anyone plumbing HForm into ADFSFiler is taking the whole “you can kill RISC OS with one click” to rather extreme lengths. ;-)

There’s an argument for a Windows-like “Properties” dialog, but formatting needs to be buried behind a lot of “are you REALLY sure” stuff.

I know it’s RISC OS, but… :-D