!HForm feature request.

Could !HForm be modified to read any existing partition table, and if one with a valid first physical partition exists, give the option to format just that part of the disk (and preferably set the partition type to ADFS)?

This would allow a disk to be partitioned on another OS, leaving a first partition for RISC OS format and use, making multi boot systems far simpler to set up, and allowing external drives to be shared safely between ADFS and extfs or NTFS.

The author of SDFS itself and CloneDisc and SystemDisc has it in mind to/is in the course of/ finalising a new formatting program to, novelly, be called FormatDisc.

However, I expect that he has been a bit busy with his day job with BroadCom.

FormatDisc

FormatDisc would be fantastic to format big data oriented discs.

I don’t think Ben has done work for Broadcom, he has done a lot of work for the Raspberry Pi Foundation on Raspian. Unfortunately he’s not been able to get them to sponsor any of his work on RISC OS for Pi, and I believe he had to take a week off from paid work to get RISC OS working on the Pi3. Thanks Ben.
I wonder if there is a need for a bounty to cover such work. There is only so much work he can do for free? AIUI all the early Pi work he did e.g.SDFS (which must have been many full time weeks of work) he did for free.

I was thinking more of a (presumably) simple change to !HForm as an interim (prior to the bounty completion).

It would need to be able to read a partition table, check for a suitable valid entry, then use the end of that for the limit of the disk (and not overwrite the partition table while it formats).

I don’t see much need for it being able to format more than 256 GB until the filesystem bounty is complete.

The other alternative would be if someone could upgrade one of the linux utilities to format adfs.

https://www.riscosopen.org/bounty/polls/10 seems to suggest that it’s a bit more complicated than just updating HForm.

Jess: I wasn’t thinking of an !HForm bounty but one that covered the porting to the next and subsequent versions of the PI and such things. Which is difficult as they will be under NDA when they are needing done.

Chris: My post was written at the same time as yours, I can see how it looks like a reply. I wonder if the filesystem bounty should be broken into smaller components?

Steve: The whole bounty would give RISC OS full GUID and MBR partition capability, meaning it could use ADFS in any partition, meaning multiple OSes or installations could co-exist very easily on one drive.

I believe this is the biggest stumbling block to RISC OS use. Casual users will be less likely to try it, with the current situation, and serious use is harder. (Much easier to use a nice but limited system, if it is a simple reboot to a less pleasant OS that does what you need or even a single use system)

Currently ADFS does not support partitions, just whole disks, however since it is possible to only partially format a disk and an MBR partition table can co-exist with ADFS, RISC OS can effectively use the first physical partition. (I don’t know if ADFS deliberately leaves the MBR alone or it needs to be marked as defective to avoid it being wiped if the filesystem fills up completely).

A method of generating such a partition would go a long way to solving the multiple boot problem.

The obvious options other than a dedicated new utility are.

An fdisk program that will create a partition table and make an entry for an existing ADFS formatted area.

HForm able to use the first physical partition for its limits.

Raspian disk utility upgraded to supoort ADFS partitions.

(All these would need a system other that RISC OS to do the some or all of the preparation, but that doesn’t matter, since it is to allow multiple OS use anyway.)

Currently ADFS does not support partitions, just whole disks, however since it is possible to only partially format a disk and an MBR partition table can co-exist with ADFS, RISC OS can effectively use the first physical partition. (I don’t know if ADFS deliberately leaves the MBR alone or it needs to be marked as defective to avoid it being wiped if the filesystem fills up completely).

There’s a bounty for that, anyone wishing it was on their list should open their wallet to bump up the total

No, there’s a bounty that includes my request along with major changes in the filesystem.

I am purely requesting changes to the disk preparation tools, so that in effect we get a degree of partition support with the current system.

(And I did donate to the fs bounty.)

Although I’ve thought idly about RISC OS disc partitioning over several years, one issue has just occurred to me.

Which partition would the various DiscOp and DiscOp64 operations refer to? Would they refer to the current partition (so the caller doesn’t need to be concerned with finding which partition is in use and adding offsets to addresses), or absolute addresses?

If they are relative to the current partition, how would one access the partition table when this is necessary, e.g. for HForm or its successor?

DiscOp64 doesn’t do anything at present – just routes through to standard DiscOp.
Perhaps each partition could be a separate drive number – thus needing a lot more than the current limit of 8.

Suggestion:
A whole new system that meets modern needs, and also maps the partitions to sub folders in resourcefs, in a similar way to linux.
Then there could be a mountfs that allows these to be mapped to its drive numbers, (in the same way as network shares) so that anything that would be confused by folders in resourcefs (including users) is happy. If more than 8 mounts are needed, it could possibly spawn mountfs2 to get more.

However, I am actually wondering if I wasn’t clear in my request. All I was requesting was a tool that would allow the creation of an ADFS partition at the beginning of a disk with a matching MBR partition table entry, so other OSes know it is there and can partition the rest of the disk.

This should mean that a 2TB USB drive could use the first 256GB for RISC OS and the rest NTFS/ExtFS or a multiboot system could be set up manually.

Even a tool that reads and existing ADFS area and creates a partition table (or entry) would work.

Yep, that’s a good idea.