How to get list of all present disc drives? (RISCOSCloverleaf)

Hello,

I’m writing Filer like application and needs to get the list of all available (mounted) disc drives (like A: C: D: in Windows).
How to get it? I’m found only SWI OS_FSControl 13 but it still needs the file system name and seems not what I need…

It can take a number. There’s a table of FS names you can refer to.

As I understand to get all available drives needs to query every FileSystem number in the https://www.riscosopen.org/wiki/documentation/show/Filing%20System%20Numbers (exclude non-disk Filesystems) and in case new File System is implemented which not included in this list then I must change the code to include this new filesystem? Its looks stupid… I hope there should be more clean way..

The way I did it with for Filecore based filing systems in the DiscKnight GUI was to use OS_Module 12 to enumerate all the modules, looking for the instances of FileCore, and extracting the postfix strings from R5, which correspond to the names of the Filecore based filing systems. Then for each filing system, I did a OS_FScontrol 37 Canonicalise path on all the possible drive paths, e.g. ADFS::0.$ to ADFS::7.$ to see if any of them came back with a different string, which would indicate a drive was present e.g. ADFS::4.$ would become ADFS::HardDisc4.$

I’m writing Filer like application and needs to get the list of all available (mounted) disc drives

Oh dear god no.

@David J. Ruck
Thank you!
Your reply is help me a much!

…similar to how it is done in many other systems

FFS no. RISC OS is not other systems. You can operate on ‘unmounted’ paths e.g. I have scripts that *Save to net#0.253:$.foo etc. There are good reasons why we do not have A: and C: drives, nor a ‘unified’ /.

@Sergey, please note that Filecore based filing systems are just one type, there are non FileCore disk filing systems, network filing systems, and image filing systems – identifying those too is far more work.

FFS no. RISC OS is not other systems. You can operate on ‘unmounted’ paths e.g. I have scripts that *Save to net#0.253:$.foo etc. There are good reasons why we do not have A: and C: drives, nor a ‘unified’ /.

But is there a good reason NOT to have simple OS calls to enumerate “drives” or “partitions”? Find out if they are RO or RW? Find out how their FSes are called? Find out if media is inserted or not?

Every filing system has to register with FileSwitch, and they can be retrieved by enumerating with OS_FSControl 13. However, not all filing systems have the concepts of drives, FileCore based ones and CDFS do, but network and image filing systems don’t.

I’m writing Filer like application and needs to get the list of all available (mounted) disc drives (like A: C: D: in Windows).

I was giving this some thought recently, as the way drives are currently presented in the WIMP is going to become an issue once partitions are implemented in the OS. We need to give serious consideration to ditching all the individual filesystem Filer icons and combining them into one Filer. The combined filer should contain all available drives and individual filesystem options then become menu options off of those drives.

Essentially we need to fundamentally change the way drives are handled in RISCOS, as the Acorn way just isn’t going to cut it with partitioning, as it’s possible to have more than 4 logical drives. Drive numbering also needs to change to handle more than 4 per filesystem.

Many of these points were raised, along with the need to replace FileCore and dropping E format etc whilst I was coding Partition Manager as what we currently have just isn’t suitable for a modern OS.

In summary, I’m glad someone is now looking at the Filer aspect. We just need to hear from the person that picked up the Partitioning bounty, to combine efforts.

I nearly spat out my coffee this morning on reading.

We need to give serious consideration to ditching all the individual filesystem Filer icons and combining them into one Filer.

It made me laugh. Someone wrote a utility to do this; strangely, it didn’t catch on. Reasons: < …New thread >

It’s quite possible to use up to eight drives with partitioning. The 4-7 being harddiscs and 0-3 being floppies is an ADFS convention. It isn’t hardwired anywhere.

Personally, I prefer drives having individual icons. I believe I’m well known for my dislike and disdain of the Unix /.

Experience? Simtec IDEFS with two physical drives (one 1GB and the other ~6GB, split into eight logical partitions).

Many of these points were raised, along with the need to replace FileCore and dropping E format etc whilst I was coding Partition Manager as what we currently have just isn’t suitable for a modern OS.

Filecore has served well but it’s time to put it out to pasture. I’m not 100% sure what it should be replpaced with, but I’d get something that exists and base it on that rather than inventing our own wheel.

In summary, I’m glad someone is now looking at the Filer aspect. We just need to hear from the person that picked up the Partitioning bounty, to combine efforts.

I wonder what’s happening with that one. I would hope that the partitioning system would present a number of partitions that whatever system could then sit on top of, be that FAT, Filecore, ext2 or whatever.

We need to give serious consideration to ditching all the individual filesystem Filer icons and combining them into one Filer.

It made me laugh. Someone wrote a utility to do this; strangely, it didn’t catch on. Reasons: < perhaps, a new thread should be opened to discuss… >

Was that MiniDisc? When Iconbar real estate was tight, MiniDisc was an absolute boon. Very nicely done. Shame it doesn’t seem to work on the Pi 4, with all those tiny case-mounted screens that are available.

In summary, I’m glad someone is now looking at the Filer aspect. We just need to hear from the person that picked up the Partitioning bounty, to combine efforts.

I wonder what’s happening with that one.

It does seem to have been a long time in coming to anything, which is a shame because other people could have looked at that bounty, I’m sure. Was there an update from ROOL about it at a show or anything? Or anything from the claimant?

Personally, I prefer drives having individual icons

Personally, I’d like to option to be able to have a different icon for each drive, not just each filesystem! A la RISC OS Nemo, and his ColourFiler screenshots. But not necessarily just coloured. Something based on, and linked to the name of the drive perhaps. If anyone wants to whip up a quick utility to do that, that’d be lovely!

Latest information on all the bounties is here about half way down … but not very detailed!

Daft idea that might satisfy diehards like me and those who want the one icon to rule them all.

I don’t think that you need a new Filer but a new RootFiler. The ADFSFiler etc modules could look at some configuration state to either create an icon and plop it on the icon bar as now, or to set up an icon just the same, but delegate it to a RootFiler, which could display all the registered icons in one window. Clicks on the icons, especially for filing system specific menu commands, could be passed to the same handler as before.

I would not welcome the creation of something like Windows Explorer as a new replacement Filer.

Was that MiniDisc? When Iconbar real estate was tight, MiniDisc was an absolute boon. Very nicely done. Shame it doesn’t seem to work on the Pi 4, with all those tiny case-mounted screens that are available.

It was a great utility, and I used it for a while. The beauty of the design of RISC OS is that it’s clutter-free, modular, so you can add utilities like Mini-disc to enhance or explore an idea.

Some of the voices here appear to be adding complexity without reasoning, other systems have this and that, so let’s add it. Then there’s a small inward-looking camp that thinks "it would be good to have a clear seperation between “Classic RISC OS” users and “Progressive RISC OS” users as each group has different goals and that produces misunderstandings". Are statements like that intended to sow division rather than bring in new people? Or have I misunderstood the intent?

What does RISC OS need? And then let’s all work towards that. Usenet is full of debates around complex topics, such as threading. RISC OS, from my perspective, multitasks well; room for improvement, of course. Rather than copying what’s everyone else is doing, be creative; Acorn was; so much so, companies are reproducing elements of RISC OS or proposing new ideas based on RISC OS concepts today.

Daft idea that might satisfy diehards like me and those who want the one icon to rule them all.

Diehard, not all; it’s how you should do it. ;)

clear seperation between “Classic RISC OS” users and “Progressive RISC OS” users

Haven’t we been here before and learnt nothing…3.7 to 4.02 to Select and then 6 and 5..all with changes and all with their own camps.

We do need RISC OS to be modernised and it needs to be a balancing act between adding features/changes in a way that enhances it for the majority whilst allowing ease of access for those that are new and used to other systems but surely if you are interested in RISC OS as a new user you are drawn to it as it is different so back to the start..

It will never be easy to progress change that satisfies all but something that is backward compatible and allows a user choice is the way to go in my view rather than something that is pushed on to a user.

The beauty of the design of RISC OS is that it’s clutter-free, modular, so you can add utilities like Mini-disc to enhance or explore an idea

Exactly, Filer does need modernising not least if/when we get partitions and also a new file system as Filecore has had its day in my view, but something like Mini-Disc allows you to decide what to do and what you want so in an ideal world any replacement/enhancements should.

Developer time is limited and I can see where savings could be made but that may not be in the OS’s best interests in the longer run.

Haven’t we been here before and learnt nothing…3.7 to 4.02 to Select and then 6 and 5..all with changes and all with their own camps.

Well, yes. And yet… we still have the vanilla RISC OS 5, Direct, Cloverleaf… and now, perhaps, Paolo OS. And fewer active developers than there were in the early noughties.

As you say, have we learned nothing?

This isn’t to say that the work being done on Direct, Cloverleaf and the RISC OS Modernisation Project aren’t useful or welcome. They are. However, implementing them as forks to the OS instead of as tools which can be loaded on top of a vanilla RISC OS 5 system¹ is perhaps sub-optimal given the extremely limited developer resources that the platform has available. Forcing an already tiny number of users and developers to “pick a distro”, instead of keeping the pool of RO5 users together in one place, seems “unhelpful”. Not least when devs are already haveing to spend their limited time supporting the differences between RO4, Select, RO6 and RO5.

¹ Which is how things like MiniDisc were done.

, but I’d get something that exists and base it on that rather than inventing our own wheel.

Good luck finding something that works nicely with the RISC OS concept of file metadata.

Daft idea that might satisfy diehards like me and those who want the one icon to rule them all.

Easy fix.
Implement a Wimp message that tells the Filer to remove its icon from the iconbar.
A replacement All-In-One can start up, enumerate the filesystems, broadcast this message, and then plonk its own unified icon in place of the existing set of icons.

That way (rather than a CMOS bit or command line flag) ensures that a replacement is actually running, so the user with a failed boot never ends up with a machine with no icons.

Then, people who want one icon to rule them all can run the tool. People like me…don’t.

Forcing an already tiny number of users and developers to “pick a distro”

I raised this at the time. I can understand Direct vs Vanilla (bells and whistles vs the minimum), but I don’t see how further distros help. Enhancements ought to be added to the base OS, or provided to Direct to add. That way there’s less risk of fragmentation.

As you say, have we learned nothing?

<turns TV on>
<goes to news channel>
<turns TV off>

Nope.

That way (rather than a CMOS bit or command line flag) ensures that a replacement is actually running, so the user with a failed boot never ends up with a machine with no icons.

Absolutely. Though I’d envisaged configuration being a suggestion to do this – if the ADFSFiler didn’t receive a response from whatever mechanism (SWI, Wimp message, whatever) it would proceed as normal.