Disc Name on Icon Bar

I have been wondering for some time how I could get the name of a USB ‘disc’ (memory stick) to show on the Icon Bar, but with no success.

However, this evening I have just installed a USB Seagate HDD drive onto my primary RC15 Ras Pi. And now my nice new SCSI drive 4 can have a disc Name showing on the Icon Bar.

So, what is different about the USB HDD, that it can show a name on the icon bar?

And why did !Hform insist that I selected drive mumber 1 to format, but then on completion gave me drive 4?

Incidently, the Ras Pi now boots quite nicely to a named 100 Gbyte Drive 4 with nothing on the SD Card but a 48 Mbyte partition with the ‘cmos’ file and the (now, readonly) boot files. (So much easier and quicker to build another new system)

And why did !Hform insist that I selected drive mumber 1 to format, but then on completion gave me drive 4?

Just off the top of my head – is 1 the device ID? This is likely related to a recent question about why a SCSI drive with ID of 6 was going to be assigned drive number :4.

Reason – simple. For hysterical raisons, logical drive numbers (that which you see within RISC OS) are 0 to 3 for floppy drives, and 4 to 7 for harddiscs. Some filing systems work around this (Simtec IDEFS let you use all numbers, but it was recommended you use 4 to 7 and then 0 to 3).
It was a thing, back in the early days when it wasn’t unheard of to have multiple floppy drives.

This nomenclature is entirely how FileCore views drive numbering, and has approximately zero to do with harddisc device IDs. SCSI, for instance, has an ID of 0 to 6 (7 is usually the controller). My SCSI drive 0 provided logical drives :4 and :5. My IDE interface had two buses, and at one time each bus had two drives, a master and a slave. God knows how you’d number those, but on RISC OS it was :4 to :7.
And so on. ;-)

So, what is different about the USB HDD, that it can show a name on the icon bar?

I wonder if there is a difference between a USB stick being considered “removable” while the harddisc isn’t? Just a guess…

the Ras Pi now boots quite nicely to a named 100 Gbyte Drive 4

Just out of interest, how to you plan to back that up? While SD cards are more space limited, and possibly life limited, there is a definite attraction to popping the card into my PC and taking an image of the entire thing. I use an 8GB µSD which takes about long enough as it does to go make a cuppa. :-)

I wonder if there is a difference between a USB stick being considered “removable” while the harddisc isn’t? Just a guess…

I’m not sure whether it’s “removability” or some sort of device ID; I believe that it’s possible for a device to report itself as either a memory card or a full-blown drive.

My configuration is similar to John’s; I have an SD card containing the ROM image, and a “256 GB”¹ drive 4. This makes it seem like a “real” RISC OS machine. In fact, since I have nothing else on the SD card I’ve unplugged SDFSFiler so it doesn’t show up on the icon bar (this doesn’t break saving CMOS settings).

¹ Actually 500 GB but SCSIFS has (had?) a 256 GB limit.

Yes. I have the SDFSfiler unplugged (but, not SDFS or SDcmos).

I will not be backing up an image of this drive, but I can re-create the drive in the same way I created it the first place by copying the contents of a standard SD card.

The other drive contents will be backed up using ShareFS and will never get anywhere near 100 GByte.
Thanks for the comments about SCSI id numbers.

I’m not sure whether it’s “removability” or some sort of device ID; I believe that it’s possible for a device to report itself as either a memory card or a full-blown drive.

There’s a “removable” flag in the SCSI INQUIRY result which SCSIFS looks for.

I have been wondering for some time how I could get the name of a USB ‘disc’ (memory stick) to show on the Icon Bar, but with no success.

It does seem to be a bit of an odd omission in the OS, that it will display the drive name for fixed discs but not removable ones. Assuming the drive reports disc change events, the logic needed should be quite simple:

1. When first clicking the drive icon to mount it (or if the disc becomes mounted via other means), update the icon to display the disc name
2. When dismounting the drive or the drive reports the disc as ejected/changed, revert back to displaying the drive number

In fact, CDFS already (kinda) does this by using different icons for CD and PhotoCD.

Potentially it could show the drive name as soon as you insert the disc, if there’s a way of getting the disc name without fully mounting the disc (mounting discs as soon as they’re inserted sounds like it could open us up to a bunch of problems – e.g. if you’ve got a corrupt disc which crashes the computer when it mounts, you won’t be able to reformat it)

The problem there is that drives with removable media don’t, in general, asynchronously report the fact that the media have changed. (This is as opposed to filing systems like SCSIFS, which support hot-pluggable drives, because removal of the drive itself is reported asynchronously.)

RISC OS is a bit unique in that you can refer to discs either by the disc name or by the drive number, and discs which aren’t physically in any drive can still be mounted. Wen you ask to access such a disc, FileCore will try all available drives to see if any of them contain it.

It would therefore represent a quirk of RISC OS’s overall UI if there was an icon on the icon bar with a disc name, you click on it, and it opens the root of a different disc. The only way to avoid that is to poll all removable drives from time to time to see whether the disc has changed – but some drives can be slow to respond in that situation (e.g. they may need to spin up the media) and since filing system operations will block the CPU for that time, you could get very lumpy system responsivity.

In RISC OS 2, you may recall that all drive 0-7 were represented by numbered icons, not named ones. RISC OS 3 started naming the hard drive icons but not the floppies – I’m sure that wasn’t accidental. You clearly need an icon for each removable drive, or you’d never be able to initially mount a new removable disc. Perhaps we could have icons for each mounted disc as well as each removable drive, rather than instead of.

You could say the root cause is USB flash memory sticks, which all IMHO misidentify themselves as being removable devices. Yes, they’re removable, but only in the same sense as a USB hard disc is. Unfortunately there doesn’t seem to be any way to reliably distinguish USB flash sticks in software from the likes of USB card readers which do genuinely have removable media.

It would therefore represent a quirk of RISC OS’s overall UI if there was an icon on the icon bar with a disc name, you click on it, and it opens the root of a different disc.

That’s why I prefaced my message with “Assuming the drive reports disc change events” :-)

Perhaps we could have icons for each mounted disc as well as each removable drive, rather than instead of.

Hmm, that would make things a bit ugly for USB sticks. You’d end up with two icons, even though the user knows there’s only ever going to be one disc.

It may also be worth thinking about how partitions will fit into things.

Only put the name under the icon if/when the user clicks the icon or the OS gets to know the name of the drive/partition in other ways. So no events necessary, no polling necessary, and it solves approximately 98% of the user’s expectations.

The only way to avoid that is to poll all removable drives from time to time to see whether the disc has changed – but some drives can be slow to respond in that situation (e.g. they may need to spin up the media) and since filing system operations will block the CPU for that time, you could get very lumpy system responsivity.

Sounds like an excellent candidate for a process to be run on a different core (if available)¹
Obviously for non-multiprocessor devices you need a fallback.

Only put the name under the icon if/when the user clicks the icon or the OS gets to know the name of the drive/partition in other ways. So no events necessary, no polling necessary, and it solves approximately 98% of the user’s expectations.

…and there you go, while I was feeding my face and watching Robert Plant on 6 music, with the post here on pause, Steffan came up with the fallback without realising it could actually be a fallback solution rather than the full thing.

¹ Probably a good idea to chuck many of the blocking processes at a different core.

e.g. if you’ve got a corrupt disc which crashes the computer when it mounts,

Come, now, Jeffrey. Fill us with confidence.

Hmm, that would make things a bit ugly for USB sticks. You’d end up with two icons, even though the user knows there’s only ever going to be one disc.

How do you mean? I have (had? not powered it up in years) a 2GB harddisc on my RiscPC. It is connected to a Simtec IDE card. One drive, five icons.
Same with Morley SCSIFS. One device, potential multiple icons.
Remember the “drives” shown in the icon bar are logical devices, not actual drives. It hasn’t been that way since RISC OS 2. That’s why we can have Apps, SparkFS, Printers, TinyDirs, blah blah. Logical representations of things. Like…partitions.

Only put the name under the icon if/when […]

There is a simpler solution, you know.

*Configure AutoMount All
If this configuration option is set, then RISC OS will probe and mount drives as soon as it is aware of their presence. This is normal for harddiscs, and can be expanded to support “removable media” of the USB variety.

Obviously this may not work entirely correctly for poor interfaces that don’t report that the media has actually changed – though two thoughts come to mind: The first is to educate people to “Dismount” devices before removing them (Microsoft managed to bang this one into many people’s heads, our reasons are similar, and if it goes wrong because somebody is too lazy to dismount, well, tough crap – do the same under Windows you risk a DELAYED WRITE FAILED and a drive that might be fixable with chkdsk); and the second thought is that I would hope that the filesystem would perform a quick sanity check (device ID or somesuch) before reading/writing data (though maybe with a rolling timeout because a minute’s worth of continual access only actually needs the one check at the beginning).

*Configure AutoMount Fixed
If this option is set, then RISC OS behaves sort of like it does now, only with the addition of Steffen’s idea of updating the drive icon with a device name when the user clicks on it.
[this can also be used should a corrupt drive crash the computer – just disconnect the drive, set this config, reconnect it]

Just to ram the point home with a pile driver, this was… my RiscPC in it’s most WTF stage, where I had a collection of older drives so could have… what was it… two and a CD on SCSI, eight on Simtec IDE, and two on the internal IDE? Something like that.
I can tell this was the RiscPC. If it was the A5000, there’d have been Econet there too…

Just to ram the point home with a pile driver, this was… my RiscPC in it’s most WTF stage,

You never discovered !MiniDisc then?

Previous discussion on these fora

Ah, but the thing is, I prefer it that way. :-)

That’s why I prefaced my message with “Assuming the drive reports disc change events” :-)

Quite. It’s a shame that most hardware is in the “doesn’t report it” camp. Of course, it would be better still if it also reported “drive has become empty” so it could be reflected in the user interface, but that’s rarer still.

Hmm, that would make things a bit ugly for USB sticks. You’d end up with two icons, even though the user knows there’s only ever going to be one disc.

Yep. I’d contend that the status quo is the least-worst solution, although it’s not ideal.

It may also be worth thinking about how partitions will fit into things.

Good point – the names we’re talking about are really an attribute of the partition, not of the disc. Obviously there’s no space under the icon for multiple partition names. You could try to pick one (the first partition? the largest one? the one with the boot flag set?) but it’s unlikely you’d ever come up with a solution that works satisfactorily for everyone. One icon per partition is possible, and has advantages such as being able to re-use the familiar “Name [partition]/Dismount/Format/Backup/Share/Verify/Free” menu options, which would mostly be per-partition anyway.

But on the downside, it could result in a lot of icon bar clutter as discs with /lots/ of partitions aren’t that unusual (e.g. NOOBS) and in the absence of hardware reporting media removal sets us up for even more UI nastiness. For example, if you’ve previously used a 3-partition removable disc and have one icon bar icon for each, then switch it for a 2-partition removable disc and click on the icon representing partition 3 of the disc in drive :0, should it generate a (probably cryptic) error, open partition 1, or open partition 2? It can’t just attempt to open the disc name instead, since that would prevent anyone from ever being able to use a disc they’ve not yet mounted. But anything else requires the user to remember which partition number of which drive each of the disc names on the icon bar corresponded to.

It’s worth noting that the icon bar filer is currently really very much a UI representation of the drive, and that’s reflected in the actions it currently takes: if you use it to perform a rename, dismount or other action, it is applied to the drive spec, not the disc spec which may be displayed below – it’s not just about opening the root directory. Arguably, the current icon sets that use pictures of the media rather than pictures of the drives are really misleading.

Sounds like an excellent candidate for a process to be run on a different core

Not really. Theres very little for the CPU to do during this time, it’s mostly waiting for the hardware. It currently blocks because the current filing systems are not thread-safe and it can’t stick a great big mutex around itself because with current kernels there’s no guarantee that any other thread calling the filing system would be able to pre-empt itself if it were to find the mutex locked. The only option left is not to return from the call until the operation has completed. Putting the code on a different core would simply replace “wait for drive controller” with “wait for secondary core to finish waiting for drive controller”.

OK. So, it is all more complicated than I thought. I will settle for just having the hame of the HDD on the Icon Bar. The drive will be updated to SSD tomorrow.

Incidently, I have just plugged in two USB memory sticks each named HardDisc0. NOT a good idea! It seems the only way out of the resultant “Ambiguous disc name” message is a shutdown.