Partition Manager

Just a few word to my solution Raik mentioned.

- The SCSIFS module is for the Titanium and PartMan aware (as mentioned by David Pitt).
- The PartMan module recognizes MBR paritions too (additional to GPT)
- The partiFC tool recognize a FileCore format and creates a MBR parition table with a protection patition for the FileCore Disk and a FAT32 partition for the otherwise unused disc space.
- The Fat32FsPM module ignores clicks to the FileCore partition icon (otherwise you may end up with two drive numbers pointing to the same partition).

So on my Titanium, with a USB drive, prepared with partiFC, SCSIFS shows two icons, one for every paritions. It works for me, but not extensively tested. And my approach does not work with SCSIFS as boot file system.

I’ve updated the OP to detail the main goals and what is in/out of scope as I feel the conversation about PartMan is adding confusion to the purpose of this project.

Reading between the lines, PartMan is possibly doing something non-standard and as a consequence hasn’t made it into the main builds. Until that issue is resolved, it can’t be used by this project to create the underlying partitions and should be considered out of scope.

Sounds pretty good to me.

The situation with PartMan and the changes tom SCSIFS etc. which have not been merged into the main ROM branch… Well… It sounds like madness. Surely the redefinition of R2 is easy to solve with a new reason code or SWI? Appreciate that this isn’t your issue, Jon, but it would be nice for someone else to maybe take an interest in that bit.

One thing I should like PartMan to dois to be able to extend the size of a filecore partition without wiping the files that are present.

PartMan wont be able to do that. I’ve looked at the problem of resizing filecore partitions again and again, and always come to the same conclusion – its not worth the risk or the effort.

There are two main issues; firstly the middle. Filecore fills from the middle of the disc outwards (to reduce seek times on spinning media), so unlike other filing system which fill from the start, resizing the disc moves the middle and all the files with it. Secondly is the Large File Allocation Unit, Filecore is wedded for life to the value used when creating the disc, if this value changes not only does the alignment of all files on the disc change, but the map must be entirely re-written and the sequence number of every file stored in each director also needs to be changed.

The upshot of these two points is that the entire disk has to be re-written, which is a very lengthy process. Not only would it be very difficult to do this in place, but any fault or interruption during the process would probably cause the entire disc to be lost (without even more complexity).

Copying everything off, reformatting and copying back is undoubtedly slower, but then uses 100% legal Filecore operations, and should the worst happen, you still have a backup. Either that or port a filing system which supports resizing.

I’ve put a mock-up image of how it might look in the OP.

Surely the redefinition of R2 is easy to solve with a new reason code or SWI? Appreciate that this isn’t your issue, Jon, but it would be nice for someone else to maybe take an interest in that bit

The correct route to take would be for John or Andrew to post the proposed change(s) in the Code review forum. It can then be reviewed, discussed and ensured to not break things when it’s modified and resubmitted.

One thing I should like PartMan to dois to be able to extend the size of a filecore partition without wiping the files that are present.

As David points out, it’s pretty complicated and comes with some major risks, but its something I personally require so plan to implement once I’ve implemented the basic partitioning and formatting.

I’ve put a mock-up image of how it might look in the OP

Mock up looks to cover most of the needs of even basic users.

I won’t say it’s idiot-proof as that just begs for a better class of idiot to turn up.
That aside I think it should cover the needs for people to do things without requiring a mega-geek certificate.

Nice screenshot/mockup. The clever bit will be getting drag-and-drop implemented to resize those partitions!

I guess it moves along a part of the filesystem bounty. Yes, we still need support in the boot-up and filer icons etc., but this is a nice way of breaking down a large task.

I’m going to make a start on the WIMP side first, along with the partition table reader.

I’ve yet to figure out some of the basic requirements, such as how to get the physical size of the underlying disc, RISCOS doesn’t implement a MiscOp for it, so it’s a case of resorting to undocumented methods. Does anyone knows a better way of doing things:

• IDE – do an IDENTIFY command directly via the controller? Not ideal on RO3.11 as there’s quite a few proprietary/undocumented IDE podules out there from various defunct suppliers
• SD – I believe there’s an undocumented SWI to get the physical size
• SCSI – INQUIRY command?
• Acorns HD interface (ADFS on RISCOS 3.11) – no idea

As I loathe using undocumented features, I’m going to be slowed down whenever I need to add the documentation to the Wiki. I’ll translate the source into relevant wiki pages before I start coding, as it’s painful at best, trying to code off of someone else’s source because they didn’t document it! SCSI is the worst culprit here.

Why devs don’t add documentation when features are added to the OS is beyond me – it should be a requirement before acceptance of the source into the tree.

I’ve yet to figure out some of the basic requirements, such as how to get the physical size of the underlying disc, RISCOS doesn’t implement a MiscOp for it, so it’s a case of resorting to undocumented methods.

I would have said like the current HForm via (IIRC) the DescribeDisc SWIs, but then is it supposed to describe the physical disc or the partition?

SD – I believe there’s an undocumented SWI to get the physical size

There is some information on SDFS here.

SCSI is the worst culprit here.

Does SCSI_Initialise, 2 not do what you want?

As André says, I think that Hform already has some incantations to read the physical media size.

is it supposed to describe the physical disc or the partition?

Given that this will need filesystem support (as traditional filesystems don’t support partitions, those that do have been third party extensions), I think it would be best for DescribeDisc to return information on the partition unless a magic value (“PART”?) is given on entry, in which case it describes the physical media. Extra benefit – if the results are the same both ways, the drive isn’t partitioned…

I would have said like the current HForm via (IIRC) the DescribeDisc SWIs, but then is it supposed to describe the physical disc or the partition?

FileCore_DescribeDisc is FileCore specific. I need the physical disc info. It’s also not that useful for describing a FileCore partition until it’s been modified to handle partitions. It can be used on drives that have a FileCore partition that fills the disk.

Does SCSI_Initialise, 2 not do what you want?

I’ve no idea, SCSI has never been documented! HForm appears to use it, so its possibly what I’m after.

SCSI has never been documented!

That SWI was described in print in 1990. There’s one on Ebay if you fancy it in hardcopy :-)

That SWI was described in print in 1990

Perfect, thanks for the link. We just need it adding to the wiki.

Speaking of physical disk vs partitions, do we have the means to distinguish them?
If we have “XXXFS::4” and “XXXFS::5” how do I know if we have 2 disks, 2 partitions on the same disk, 1 partition + unused space on disk1 and 1 partition on disk 2?

This reminds me of this old topic with suggestions to use conventions like “fsname#partition_nr::drive_nr” or like my suggestion to introduce a disk/device manager API so that there is a central uniform way to manage disks for tools like HForm, DiskKnight maybe even disk icons management.

How do existing partition managers handle this stuff? Note for that matter, that since the bounty is underway, we can ask the same to the developer that accepted the bounty.

How do existing partition managers handle this stuff?

My experience (Morley SCSI and Simtec IDE) is that the partition looked like a drive. You could have one physical drive in four partitions, or four physical drives. They’d be identical as far as RISC OS was concerned. Reading sectors would read relative to the partition. This is by design, as you really want them to look like separate devices to RISC OS.

There is probably some secret undocumented call to read raw sectors, so that the partition table can be accessed and manipulated.

how do I know if we have 2 disks, 2 partitions on the same disk, 1 partition […]

Why does it matter? If you installed the machine, you’ll know how it is laid out. If you didn’t, fire up the formatter/partition tool and see what it says.
But from the point of view of RISC OS and applications, you have n storage devices. Whether it’s one disc or four shouldn’t make any difference.

I recall many years ago using a partitioned drive on an old PC which gave a C drive of around 300MB and a D drive of around 200MB. When I looked inside the machine (cleaning the fans), I was surprised to see only one drive despite the C and D. Don’t know why it was set up this way.

When I looked inside the machine (cleaning the fans), I was surprised to see only one drive despite the C and D. Don’t know why it was set up this way.

One good reason for doing this is fragmentation. The swap file, by default, grows and shrinks – a lot. If it’s in the same partition as other active files, usually user files, then it and the user files get badly fragmented. It can also cause operating system file fragmentation. I had a Windows XP computer with 3 partitions – C to boot from, D for just the swap file, and E for user data. As a result it didn’t lose a noticeable amount of performance over a 5 year period. Windows usually (until Win 8 onwards) lose performance steadily over time, for this reason. Win 8 ( I think that’s the first) automatically defragments, which improves things.

SCSI – INQUIRY command?

SCSI READ CAPACITY. First the 10 byte cdb version, if that returns the max do the 16 byte variant.

Look for the SCSI-3 command set stuff, e.g. SBC-3: https://t10.org/ftp/t10/document.05/05-344r0.pdf

How do existing partition managers handle this stuff?

For existing RISC OS SCSI and IDE solutions, it was never possible to distinguish between a drive and a partition – from the “plain RISC OS” side of thing. The podule firmware looked at block 0 of the device (or the boot block? I don’t remember…) to detect partition data (and this was not interchangeable between different SCSI or IDE podules), and mounted the partitions accordingly. The partition data was usually just a sector (block) offset for the supported 4 to 8 partitions.

I think the Power-tec SCSI podule was the only one that understood most other partition schemes and could convert it to its native format.

I ported disktype and added an ADFS reader to it. It detects a wide range of foreign disks by using *disktype SCSI::0
or ADFS::4 etc, might do floppies too I think.
I dont think it detects a pi card fat and adfs partitions in one attempt though.
I have the C source code I added for ADFS (with a little help from Ben) if it is of any help.

Why does it matter? If you installed the machine, you’ll know how it is laid out. If you didn’t, fire up the formatter/partition tool and see what it says.

For Jon it matters. How will he be able to display disks and partitions if he cannot tell the difference between disks and partitions or map the existing partitions ?

I ported disktype and added an ADFS reader to it. It detects a wide range of foreign disks by using *disktype SCSI::0 or ADFS::4 etc, might do floppies too I think.

Is that a port of Christoph Pfisterer’s “disktype 9”?

If so it should include the licence file, which is pretty open: just requires the inclusion of the licence file with any copy or altered copy or subset.

I dont think it detects a pi card fat and ADFS partitions in one attempt though.

Given the abuse of disk access that’s involved on that I wouldn’t blame the software if it had a total epi-fit.
As soon as RO has partition support the kludge for Pi filecore/FAT dies…

it should include the licence file

I have removed the link, It is a straight forward job in GCC should you want to build it yourself. Have limited time until next winter.