USB Stick as drive 4

In a discussion with a fellow RISC OS 5 user he got a question whether it is possible to format an USB memort stick as an hard disc, as far as I know this is not possible as RISC OS recognizes the type of USB storage and either handles it as a floppy disk (:0 … :3) or a hard drive (:4 … :7).

When asking for the use case the response was that the actual use was to be able to switch between USB memory sticks or hard drives where both would get the same drive number so that no re-configure is required when replacing an USB hard drive with and USB memory stick and vice versa.

When it is not possible then it would be a nice idea to have an option in SCSIFS/USB to have the options where we could have one device for which we can define which drive number it is going to use (e.g. :7 or even better :8) so that it is outside of the normal assignment and still a default configure option is possible which doesn’t have to be changed when exchanging an USB memory stick with an USB hard drive.

Having the same drive number is a red herring as they will be on different file systems SCSI::4 or SDFS::4

The idea is to have SCSI::4 for a hard drive and SCSI::4 for an USB memory stick – SDFS is not part of this mix.

If it is removable it will be drive 0 not 4. Formatting is identical whether it is a removable or fixed SCSI drive.

Whilst SCSI::4.$ (and SCSI::0.$) will not do what you are looking for.

Using a named disc (SCSI::MyDisc.$) may do what you want as the same names can be given to hard drives and memory sticks. (Obviously not both at the same time – and may need a system restart, when changing – I have’t tried it)

The issue is that when replacing a hard drive with an USB memory stick a reconfigure of the boot drive is required, it would be nice when that is not required.

For me personally it would be nice to have an option to set a fixed drive number for a certain USB stick so that in case I would keep a secondary USB stick in the system it is not in the way. (E.g. becoming :0 although another one should have been :0 but due to the USB priority the wrong one becoming :0).

Obviously not both at the same time – and may need a system restart, when changing – I have’t tried it

Provided you *DISMOUNT the drives before you switch you should be okay, you just need FileCore to forget about the volume serial/name combo. This particular problem is one I’m currently trying to solve in Partition manager when you initialise a drive or format a FileCore volume that RISCOS has seen before.

get the same drive number

This is also a problem I’ve noticed whilst coding Partition Manager, RISCOS is allocating random drive numbers every time I format another partition. A drive might start off as ::4, add a 2nd partition and the 1st volume might then become ::5

FileCore really needs a drive number hint in the Disc Record

The issue is that when replacing a hard drive with an USB memory stick a reconfigure of the boot drive is required

I would hope this particular issue is fixed when partition support is added as UEFI/GPT choose the boot drive from the GPT, not the BIOS.

I think it is just the screen saver that has an explicit path name.

RISCOS is allocating random drive numbers every time I format another partition

Drive numbers shouldn’t be important for normal filing system use as we access discs by name. Several filing systems now don’t make any distinction between removable and fixed drive numbers like ADFS does. There are a couple of *command’s which need a drive number, but they aren’t everyday things. Oh and of course make sure you know the drive numbering before you format any drive – there is no coming back from that.

FileCore really needs a drive number hint in the Disc Record

The drive number is a “physical” thing and surely does not belong to the logical data describing a filecore “disc”? What will happen when there is a collision when inserting USB sticks from different systems with different drive numbers allocated?

IMHO, RISC OS needs a way to explicitly link disc specifications to drive numbers and restore that on reboot. Having disc/partition names on the one hand and having user-facing drive numbers on the other hand (checkmap, verify and surely a few other commands, and additionally the configuration of the boot drive as well as HForm using drive numbers) is a very user-unfriendly way of operation. Makes Windows-like drive letters seem like a good idea.

All the user friendly stuff should be available from the drive menu (like verify), and that should be expanded for other things such as boot options.

HFORM needs to stop using drive numbers, and show you a list of target drives and what is currently on them, so you are sure you know which one you are going to format.

A. 128G SSD Filecore format - CURRENT BOOT DRIVE
B. 512GB HD Unrecognised format

Select A or B (strongly suggest B):

I agree David, and ideally BootUI would present discs in this way as well.

Drive numbers shouldn’t be important for normal filing system use as we access discs by name

Quite, however I was referring to Partition Manager and what can happen after you add and initialise a partition.

It creates several issues that I can see. Firstly the drive order can change, secondly FileCore can get confused and think it’s seen duplicate drive names.

The drive number is a “physical” thing and surely does not belong to the logical data describing a filecore “disc”?

It wouldn’t be my first choice of location, I’ll agree, but I don’t know where else it would go as we have no BIOS or UEFI drive selection. It has to be done before the boot drive is chosen, so possibly extend CMOS to include drive ordering and ditch the Filesystem setting?

Windows probably has the most user friendly way of handling it at the moment, with UEFI choosing the boot drive and the registry holding every drive ID and drive letter hint or logical path. When you format the drive you specify the drive letter you would prefer, which becomes the hint stored in the registry.

ideally BootUI would present discs in this way as well

If BootUI could implement the UEFI’s spec and become part of the OS pre-boot process, that would cover the boot drive – and complete that part of the partition bounty.

I’m not sure what the state is with the bounty, if the developer is someone here, they’ve not made it obvious or responded or my request to RFC before its implemented.

The issue of Filecore getting confused over drives it has seen before is different from allocating drive numbers. If I remember correctly from floppy disc days, it was done on disc name a cycle number (incremented on each write operation). What is needed is for the formatter to put a UUID on the disc, and Filecore recognise that, so if someone has half a dozen drives call HardDisc4, they are all seen as different discs.

That wouldn’t work. A copy to :HardDisc4.$.x would no longer be unique. So do you copy the target to all of the possible destinations?

If I remember correctly from floppy disc days, it was done on disc name a cycle number (incremented on each write operation). What is needed is for the formatter to put a UUID on the disc

GPT has a UUID for each partition, so that particular issue could be resolved as part of the partition bounty. Cycle ID is still a thing on HD’s, but it should probably be removed as it causes lots of writes to the same LBA.

Related problem: I have a disk in a USB-SATA adapter permanently plugged in. Safestore backs up to it, and before Safestore runs it runs a command to mount the disc, as it isn’t always mounted.

The mount command seems to need the drive number.

I had two internal hard drives connected, but recently had problems with one of them, so it’s temporarily disconnected.

Before this change Fat32FS mounted the disc as FAT32_6. After this change it’s mounting it as FAT32_5. As a result the Safestore job failed as it couldn’t find the destination drive.

edit: I’ve found the Name Disc option, but it doesn’t allow the disc to be mounted by name, only drive number. I’ve fudged this by using the X form, and mounting both 5 and 6. One will silently fail. Not pretty.

but it doesn’t allow the disc to be mounted by name, only drive number

This is indeed the flaw I pointed out. Under the hood everything is based on drive number, so when physical or logical drive counts change, so potentially do the drive numbers.

It’s not been much an issue to date as people don’t generally change physical drives, but with the advent of removable drive support and logical drives in the near future, it’s going to become an issue a lot of folk suddenly become painfully aware of.

My problem with Partition Manager is ensuring it knows the drive number of every logical drive. I don’t think people will be impressed when they format a partition only to find out another existing drive/partition got wiped because the OS changed the drive numbers after initialising a new partition.

My problem with Partition Manager is ensuring it knows the drive number of every logical drive.

This might be a red herring, but I wonder whether there’s anywhere on a disc/partition where you could write a signature before doing anything? I’m thinking put a signature on every relevant disc before re-initialising, so you can check which one you are really about to work on.

This might be a red herring, but I wonder whether there’s anywhere on a disc/partition where you could write a signature before doing anything? I’m thinking put a signature on every relevant disc before re-initialising, so you can check which one you are really about to work on.

I think you’re talking about the sort of thing used by GPT – the GUID

I think you’re talking about the sort of thing used by GPT – the GUID

Possibly. The scenario seems to be, the machine has discs 4, 5 and 6. A new partition is initialised on one and we now have 4,5,6 and 7, with no reliable way to detect which is the new one.

My thought was to write something somewhere unimportant into 4,5 and 6 before starting which when read back would identify them. After creating the new partition, check each drive for that “flag”. The one without is the new one.

The something somewhere is the disc name! The formatter should ensure that discs/partitions are uniquely named on the machine, so regardless of the underlying disc number, the human recognisable identifier is always maintained.

The something somewhere is the disc name!

and if mr/mrs/ms numpty gave them both the same name? – fail.

I bet you’ve done it yourself and called yourself all the names under the sun, it’s even more likely for non-tech users.

Nah, Globally Unique is the way to do things. If there’s anything unique in the physical device you can read, ideal. Otherwise, a value calculated from several factors.

The something somewhere is the disc name!

Unfortunately the disc name is not a globally unique identifier. It needs to be GUID based for both the physical and logical drives.

A GUID is for the system to recognise which disc is which, users should never see it, they want to see a recognisable disc name below the drive icon. So what I am suggesting is an formatter doesn’t just offer “HardDiscX” (where X is the drive number) every time you format a disc, but asks you for a name (perhaps suggesting something like “USB16GB” or “SSD480GB”), and checks it doesn’t match the name of an existing drive. Then no matter what happens with drive numbering after creating partitions, the disc you have just formatted cannot be mistaken for an existing one.