USB Stick as drive 4

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.

You’re right on the first bit and then lose the plot talking about arbitrary labels as though they were significant.
Jon is talking about a utility that needs to ensure it doesn’t misidentify a disc or volume, you’re talking about decoration to keep humans happy.

A GUID is for the system to recognise which disc is which

Correct

users should never see it, they want to see a recognisable disc name below the drive icon

Also correct

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

This is not possible as there is currently no public method to ask FileCore if it has seen a disc name. Bare in mind we are not talking about just currently inserted discs here.

Also consider that you could dismount a disc and put a new one in with the same name.

Disc name should bare no relevance to the underlying disc, it’s simply a user name for it.

Then no matter what happens with drive numbering after creating partitions, the disc you have just formatted cannot be mistaken for an existing one.

If only it were that simple. There’s no getting away from it, we need to modify FileCore to use GUID’s instead of disc name as a unique reference.

We could extend the disc record and include a GUID, or simply correct the issue as part of the partition bounty. I’m not sure about floppies though – perhaps we forget they exist for the minute as our main concern is HD.

Quite a few SWI need modifying to be GUID based – it might be easier to add GUID<—>drive number translation SWI’s and make the drive number a reference ID instead. At some point we’re going to have to break backward compatibility though, to allow the OS to move into the 21st century.

Meanwhile can we do something about the ‘Ambiguous disc name’ error. If you remove a disc (without dismounting it), take it to another machine, update it, then bring it back to the original machine, can we have a way of telling the OS to forget the fact that it ‘knows’ that disc, to throw away any pending updates and to treat it as a fresh disc? Perhaps an option to ‘Ignore’ the error and mount it as a fresh disc. Otherwise it is a power off/on.

Disc name should bare no relevance to the underlying disc, it’s simply a user name for it.

This.
Plain simple label for humans, not relevant to the machine.

This is not possible as there is currently no public method to ask FileCore if it has seen a disc name. Bare in mind we are not talking about just currently inserted discs here.

It’s quite easy to enumerate the current discs though. As the aim is to avoid confusion when creating new drives/partitions it doesn’t have to be world unique, i.e a name FileCore has never seen before, just different than any currently attached drive.

Also consider that you could dismount a disc and put a new one in with the same name.

Entirely different problem.

Entirely different problem.

Different side of the same.
Caused by a setup that can’t properly distinguish between drives after a connect/reconnect event because it currently relies on an arbitrary label.

not relevant to the machine

Well ShareFS uses it also, it wont work if the machines have ADFS::4 on both.

It would be nice to get rid of drive numbers completely, not least because of the restricted range.

Using IDEFS on a Unipod, the boot drive doesn’t get identified by (user-visible) number. This can get a bit odd if there are two discs on the unipod with *opt 4,2 set, as it’s not clear to the user which will be booted. My suspicion is that the search order is fixed, either channel 0 master, then channel 1 master, then channel 0 slave …. or alternatively master than slave on the first channel, followed by the second channel. It does at least eliminate one need for the user to deal with drive numbers.

Back when I was working with WindowsXP (might be different on later versions) if you told it to use, say J for one of your plug-in devices it would always try to use J for it. A side effect was that it would not allocate a drive letter lower than J to anything else. I have a vague recollection that there was a special letter later on – N maybe – beyond which letters couldn’t be allocated either, so even with letters, it was possible to run out. 4 is just ridiculous now, especially with 4-slot USB card readers.

I have a vague recollection that there was a special letter later on – N maybe – beyond which letters couldn’t be allocated either, so even with letters, it was possible to run out.

Possibly Z.
I had various drives I used to map in on Win2000 onward and Z was a regular, and it didn’t cause any problem mapping lower letter drives.

Well ShareFS uses it also, it wont work if the machines have ADFS::4 on both

Nice example of misuse of an arbitrary label.¹
The exposed share should be machine_network_name/shared_resource_identifier thus making two identically “named” shared resources different on account of the differing machine_network_name.

¹ When you look at the User Guide and check the Acorn era content that is basically suggesting that to avoid identical shares you should rename the source disc so that each one is distinct it’s clear that Acorn expected users to plan out a shared network by either co-operation of users or diktat of the network manager. It doesn’t work.
Even in an enterprise network situation unthinking people turn up all the time with cloned machines identically named.

It’s quite easy to enumerate the current discs though

If you’re talking about a static setup and ignoring FAT, yes, the current volumes can be enumerated.

It doesn’t however get around the issue of the disc name having been seen before, as far as I know there’s no public method to clear the FileCore disc name cache.

I’m at the point where I think I need to write my own code to enumerate FileCore volumes, as the OS is for want of a better word, unreliable.

when creating new drives/partitions it doesn’t have to be world unique

Unfortunately they do, it’s in the GPT spec. If/when we go GPT each volume has a GUID and should be tracked by that and not its disc name – which is irrelevant.

As I said this is two issues:-

1) The OS tracking discs via a GUID, so it knows when they’ve been seen before
2) Users becoming confused which drive is which due to drive number changes

I’m talking about (2) and making sure that a name isn’t used for a newly created disc/partition that duplicates what is in the machine at the time.

GUIDs are no help for (2) as the user wont see a long string of alphanumerics under a drive icon. Similarly short names are no use for (1), hence two issues.

GUIDs are no help for (2) as the user wont see a long string of alphanumerics under a drive icon.

I’m afraid there is no help for confused users.
We have 9000+ on the payroll and a steady changeover of most of those, but the problem never changes.