Filing system improvements (step 2)
Building on the foundations laid in step 1, this next step will bring support for industry standard media partitioning to the native RISC OS filing systems.
It is relatively common for desktop operating systems to be able to interpret one physical drive as a number of logical drives (partitions). There may be several motivations for this:
- safe separation of critical operating system files and user data
- allowing boot time selection of Windows or Linux for example for disc based OS choice
- splitting larger media into smaller more manageable drives
One example of particular relevance to RISC OS is the Raspberry Pi initiative which expects to boot from a FAT format media but may ultimately end up in an operating system with its own native format – such as RISC OS with its FileCore format.
While historically vendors of RISC OS upgrades have tried to provide support for partitions, for example with SCSI expansion cards, this has never been standardised across RISC OS, and in general the partition scheme was in itself proprietary and hence not interoperable with other popular systems.
The two prevalent partitioning schemes around today are the master boot record originally conceived for DOS and the GUID partition table. The latter is more modern and extensible particularly for huge drives (the subject of a future bounty), the former is often encountered on more embedded devices. It is expected that both will be supported.
It is likely to be necessary to adapt the user interface to handle partitions, for example the traditional desktop filers present one icon per physical drive at present – whereas with partitioning the user will need some way to select which partition is desired.
Similarly the boot process, which searches a drive number for a file called !Boot may need adapting to select the most appropriate partition, or a default one if none are natively formatted.
In addition, the ageing HForm application will need rewriting to cope with being able to lay down partitions, or at least respect any partitioning scheme it finds before writing the FileCore formatted area. A desktop front end using the standard Toolbox may be used to present the information more clearly than its current command line form, though a scriptable interface would be beneficial – particularly so that 3rd party filing systems can make use of its facilities without needing to replicate the functionality.
It is not expected that the native RISC OS format, FileCore, will be extended in this bounty. Therefore its limitation of 229 sectors, 212 bytes per sector, 20 partitions per drive, and 23 logical drives will be retained.
- C source code to handle partitions within RISC OS
- Replacement HForm utility
- Updated source code to FileCore, and if applicable its clients/filer front ends
- Documentation of the new partition support, and any known limitations
More information about the bounty scheme
Bounty scheme discussion forum