Can't rename SD on Pi?

Hi,

I’m not sure whether this is a bug per se or whether I just don’t know what I’m doing :)

Some background: Upon trying to run an app (which I probably didn’t install correctly) I got the message “Filing system SDFS: must be given a filename – LI_96”. “Simple”, I thought; “I just need to give the SD card a name since I haven’t done that yet.” As it happens, the card already has a default name of RISCOSpi but I didn’t realise that and tried to rename it anyway.

So, the problem: First of all, menu-clicking on the SD card in the iconbar and going to “Name disc” gives an empty box. Should this have the existing name displayed?

I gave it a new name and it accepted it, until I tried to open another app. “Please insert disc ‘RISCOSpi’”. Well, RISCOSpi no longer exists because I’ve just renamed it!

Naturally this issue is trivial to avoid now that I know about it, but it could potentially trip up other people. Does it look like something that needs to be changed, or is this just a case of user error? :)

First of all, menu-clicking on the SD card in the iconbar and going to “Name disc” gives an empty box. Should this have the existing name displayed?

No, it only shows the name for fixed discs – anything removable will be empty since it can’t be confident you’ve not switched discs behind its back. Doubly so on a RPi since they forgot to wire up the card present microswitch!

I gave it a new name and it accepted it, until I tried to open another app. “Please insert disc ‘RISCOSpi’”

If you just renamed the main boot disc then there are any number of things pointing to it (system variables, applications with files open, etc) so you’ll need to reboot to get all those reevaluated.

the message “Filing system SDFS: must be given a filename

This message is a bit misleading. It arises very occasionally on most systems. It is not the drive that the filer cant find – it is the file. If it was looking for a drive you would get the message “Please insert drive X” or whatever. The error you saw often arises because a system variable has not been set, and when the name is cannonicalised the filename is invalid. Eg. if the ‘filename’ is “<Myapp$Dir>.myfile” and myapp$dir is unset, ie. empty, the filename becomes eg. SDFS::.myfile which is invalid. In your case – you admit the app maybe wasn’t installed correctly (package manager anyone 8)) – it probably means that an obey file which sets up system variables hasn’t completed or hasn’t even been run. That’s my theory anyway.

No, it only shows the name for fixed discs – anything removable will be empty since it can’t be confident you’ve not switched discs behind its back.

The ability to name discs had been there since 5.25" DFS floppies, why remove it?
Or have I missed something?

it can’t be confident you’ve not switched discs behind its back.

Couldn’t ADFS spot discs being changed even when the disc changed line on the 34way cable was disabled?
Would it be difficult to ReRead the disc title or map CRC

The ability to name discs had been there since 5.25" DFS floppies, why remove it?

I don’t think it has been removed. It is just that the menu writable icon isn’t filled in with the current name. If you simply enter the new name and press return the stick/drive is renamed. I renamed a memory stick this morning, although the name writable was initially blank.

What is more to the point and much more noticable – the name of filecore formatted sticks no longer appears under the iconbar icon, it just says :1 etc, although Fat32Fs still puts the name on the iconbar.

Edit: I should add this is 5.19 on Iyonix and ARMini.

the name of filecore formatted sticks no longer appears under the iconbar icon, it just says :1

Similarly to the name submenu contents, this is unchanged behaviour. Removable FileCore drives have never shown their disc name underneath them, only fixed discs do.

Well it looks like I’ve started up a bit of a debate :)

If you just renamed the main boot disc then there are any number of things pointing to it (system variables, applications with files open, etc) so you’ll need to reboot to get all those reevaluated.

It won’t even cleanly reboot; if I start from a fresh boot with no running apps and go straight to renaming the card then I still get the “please insert disc” message when I press Ctrl-Shift-F12. I needed to click Cancel a few times to get it to shut down. I don’t know enough about RISC OS yet to know whether this is causing any sort of damage but at the very least it’s not a great user experience.

I understand the other comments around why the existing name doesn’t appear. At first glance it seems that the OS could query the card when you select “Name disc” but I don’t know how practical this is.

It won’t even cleanly reboot; if I start from a fresh boot with no running apps and go straight to renaming the card then I still get the “please insert disc” message when I press Ctrl-Shift-F12.

Something in the boot sequence is attempting to access the device by canonicalised name.

In English, there are four ways to refer to a file:

SDFS::MyDiscName.$.Meh.Blah – will look for “Blah” in directory “Meh” on the SDFS disc called “MyDiscName”. This is the “canonicalised” version and is what RISC OS will show you in, say, !Edit’s title bar. It is a guaranteed path specifier, but means nothing can be renamed or it’ll fail.

SDFS::0.$.Meh.Blah – as above, but since we’re using ‘0’ to refer to the device by disc number, it will survive the disc being renamed. It won’t survive partitioning or more devices being added if this alters the drive numbering.

$.Meh.Blah – lazy but I tend to use it a lot in the command line. Presupposes you already know which filing system/drive is active and in use. For the RasperryPi you’ll have SDFS and if a USB flash key is inserted, SCSI as well. Where ‘$’ points ought to be the boot drive (SDFS) but this isn’t really reliable.

<Boot$Dir>.Here.There – using a predefined system variable. At boot, certain things are set up (Boot$Dir, Choices$Path, etc). Once these are set up, everything else should use them in order that the whole process be ‘transparent’ (in other words, if you can get as far as running !Boot then it won’t care about drive name or filesystem).

I needed to click Cancel a few times to get it to shut down.

Does the error box say in the title anything that might indicate who/what is complaining? Failing that, try pressing Alt-Break as one of the errors is displayed and see what the TaskKiller offers as “the current task”.

I don’t know enough about RISC OS yet to know whether this is causing any sort of damage

Probably not. Though, I’d be interested to know what is asking for the drive.

You could also try the following. Boot the machine. Then press Ctrl-F12 to open a TaskWindow.
Type:
*Show
and wait while a lot of stuff is displayed.
When it is done, click Menu over the taskwindow and choose the Unlink option.
Now go up to the top of the load of text and put the caret there (once you have unlinked, it behaves like a normal editor window).
Press F4 and in the search box, enter the name of the disc given in the “please insert disc” message. “RISCOSPi” isn’t it?
Search for that, see if anything comes up.
If something does, tell us the entire line that the match appears on, and then search again in case there’s another.
[you can close the window and discard the active task when you’re done]

At first glance it seems that the OS could query the card when you select “Name disc”

The problem here is RISC OS errs way on the side of caution. Do you query before displaying the name? Before accepting the new name? A user could unplug at any time (although unplug without dismount is silly!).

Personally, I would think that the most logical behaviour is for RISC OS to just auto-prompt with the current known drive name. After all, if the OS is going to take the line that you can’t trust the right drive is inserted, can it also trust that the right directory contents window is open? (^_^) That said, it should verify that the attached device is the one it thinks should be there before committing the name change, and not blindly go ahead and do it. Plus, perhaps for the benefit of the user, inform them that there’s likely to be a lot of p***ed-off applications until they reboot.

[although if there is a “drive renamed” upcall, it isn’t out of the realms of feasibility for an add-on to patch up all the system variables that point to the original device name…?]

The specific issue for RISC OS is that we don’t use drive names “for pretty” like under Windows. They are an intrinsic part of how files are identified.

Removable FileCore drives have never shown their disc name underneath them, only fixed discs do.

Sorry – senile moment. I use filecore formatted memory sticks so rarely, I thought the name used to be shown.

Failing that, try pressing Alt-Break as one of the errors is displayed and see what the TaskKiller offers as “the current task”.

Unfortunately that doesn’t help much; it just returns whatever I was doing when it complained. For example, it returns “Press Stop to terminate Pinboard” if I’ve tried to open an app on the pinboard or “Press Stop to terminate Task Manager” if I’ve tried to shut down using the Task Manager icon.

Press F4 and in the search box, enter the name of the disc given in the “please insert disc” message. “RISCOSPi” isn’t it?
Search for that, see if anything comes up.

You’re going to love this: Yes, it comes up… well over 100 times :)

Backtracking a bit, is this issue happening for anyone else or have I just broken something? I’ve been haphazardly installing and removing packages, unzipping random stuff all over the place and generally making the whole system a mess because it’s so trivial to reimage the card if I totally screw something up. If you want me to re-test from the original image then I’m happy to do so.

I have a slight variant on the original question, which is that I want to rename the SD Card – and have the name displayed on the icon bar as we used to have on RiscOS 2, 3 and 4. I have always used the disc name to identify the computer on which I am working. (instead of seeing the same bland SD :0 on all the computers)

It works on legacy Acorn hardware and on Virtual Acorn, so please: How do we do it on Risc OS Pi?

The SD card is actually ‘Removable’. Apparently ‘Removable’ ¹ drive names have never been displayed on the Iconbar.
It has been many years since people have booted off a removable disc and I think for most people the SD card will never be changed ‘live’. So maybe this policy needs revisiting!
¹ I could have sworn that parallel Zip Discs put the disc name on the Iconbar!

One interesting effect is that if the disc is ‘shared’ then on other computers mounting the share it will have its share name displayed on the IconBar, and the default share name is the disk name!

I could have sworn that parallel Zip Discs put the disc name on the Iconbar!

Yes, they did. At least, with Argo’s software.

Useful, I could pop in my discs to see which they were ¹ and then eject without getting sidetracked looking at the contents.

¹ Youd have thought that having taken the time to give the disc a meaningful label, it wouldn’t be too hard to scribble something on the actual disc casing? No. It’s like a terminal mental block.
Over the weekend I got the second half of the “Naniwa Shônen Tanteidan” series. Now I’ve tracked down some subs, it would be good to have it all together. But I’m looking at a small pile of SD cards with no indication of their contents… <sigh>

Chris: Actually, ROOL seems to explicitly expect a card swap, for NutPi.

(Remove RISCOSpi, insert NutPi, run installer, it copies to a RAM disk (presumably), remove NutPi, insert RISCOSpi, complete installer.)

Presumably a card reader can be used to avoid swapping out the Boot SD. I’ll try that when we get our NutPi!

Actually, the Raspberry Pi does have the SD card detect connected – it’s the write protect switch that they didn’t hook up. (*) However, FileCore supports many types of removable discs, and many of them don’t have disc inserted/changed detection – for instance, with most floppy disc drives, the drive has to be spun up before ADFS can tell whether the disc has changed or not. The way the filing system stack was designed means that there is no software notification passed up the stack from the drivers to the user interface that a disc has changed in a removable drive.

For the most part, this is of no consequence, because of a feature which I think is still unique to RISC OS: it treats discs and drives quite separately. Files can be open on a disc that isn’t in any drives. You can swap a disc from one drive to another, and it continues to work as though nothing happened. Any application can cause the “Please insert disc ‘foo’” dialogue to pop up, if it refers to a disc that’s not in any drive, without have to code for it specially. This is why it’s quite valid that filer windows remain open after the disc they refer to has been removed: they are displaying the contents of a disc, not the contents of a drive, and FileCore still knows about the disc.

The icon bar drive icons are just that, though: drive icons. It was more obvious in RISC OS 2, where they all had only drive numbers. Putting disc names under the icons instead (as well as setting a default name in the rename disc dialogue) was introduced at RISC OS 3 – however, you’ll notice they only did that for non-removable drives. The reasoning was presumably that, since it was non-removable, there could only be one disc in those drives anyway. The situation is different for removable drives, especially since there’s no way to know when a disc is removed or changed until you access it!

The more specific case of renaming the boot disc has always been problematic – whether it’s removable or not, so much software now relies upon canonicalised paths inside !Boot in particular, that the machine becomes basically unusable as soon as you do so, and practically speaking, you need to reboot immediately. It might be worthwhile explicitly prompting the user to reboot if a rename of the boot disc is detected, or even initiating a desktop shutdown, and only doing the rename once it has completed.

(*): You’ll note that given what I’ve said above, RISC OS could actually have coped better, if there was only a possibility of connecting one of the two switches, for the Raspberry Pi to have had the write protect switch connected instead of the card inserted switch. Card detect can be performed using the existing data pins (checking for pull-ups on card insertion, or command timeouts on removal), but there is no alternative way to read the write protect switch – it’s just a plastic slider on the side of an SD card, and is not electrically connected within the card itself.

renaming the boot disc has always been problematic – whether it’s removable or not, so much software now relies upon canonicalised paths inside !Boot in particular, that the machine becomes basically unusable as soon as you do so, and practically speaking, you need to reboot immediately

It has to be said that a quick s/oldname/newname on the sysvars would solve 90% of the problems at least.