www.virtualacorn.co.uk/forum

As we can not edit our own posts in this forum, I will have to add the comment here - that this whole topic is only really of interest to those people like GNA, adamr and myself who have various reasons for wanting to rename HardDisc4.
In my case, the reason is to maintain compatibility with all of my other RiscOS computers, where the name of the boot disk is derived from the computer name. (A quick and easy reminder of which computer I am working with).

Sorry, but you are mistaken. Several components in RISC OS use absolute path names e.g. PinBoard. This is for a very good reason, relative path names won't work.



I am responsible for the RISC OS build in all the VirtualRPC products and spent a great deal if time optimising and tweaking the various builds to get the best performance for the end user. You will see that the VirtualRPC !Boot sequences have lots of updated components and later modules compared with a default !Boot for the same version of RISC OS. As such I am pretty familair with how the !Boot sequence needs to operate and also with potential problems caused by trying to use relative pathnames in inappropriate places.


Which is exactly the problem - and is why AccessSet uses absolute paths. Perhaps I need to provide an example to show you the problem:
1. Lets us suppose you have a MyDocs folder on HostFS::HardDisc4
2. You set up AccessSet so this is shared.
3. You then need to install an application that requires ADFS
4. So you set the number of IDEDiscs to 1
5. Now you run the !BootADFS app on the new IDEDisc to move your
boot sequence from HostFS to ADFS.
6. You reboot - because AccessSet uses absolute paths your shared folder
(MyDocs) on HostFS is still correctly shared.
7. If you had tried to use relative paths ShareFS would now be trying to
share folder called MyDocs on the ADFS drive - which doesn't exist.
To conclude: Relative paths only work if all the files you are dealing with are on the same device on the same filing system. They fail completly with multiple devices on multiple filing systems. That's why any part of RISC OS (e.g. PinBoard) that might have to cope with multiple devices on multiple filing systems uses absolute paths. And AccessSet does the same.
i.e. it conforms correctly to the standard specified by Acorn.

Yes, fair enough.
But I don't think it's unreasonable to expect people, when installing their new VA system, to want to rename the harddisc. When I did this, the only obstacle was the SetAccess file. Unfortunately this results in quite a cryptic and unhelpful message during boot - so if it was possible to have the clean/out-of-the-box !Boot not include that one reference to "HardDisc4" I think it would be helpful
Adam

The problem is that the AccessSet file needs to be present in the default boot. The default !Boot sequence is set up so that even users who are not experienced with RISC OS can get stuff working straight away.
What you are suggesting is that I should remove functionality that benefits 95% of users in order to make it easier for 5% of users who wan't to rename the harddisc (which can still be done anyway). Sorry but I am not prepared to do that. Given that certain parts of RISC OS use absolute paths renaming the harddisc is always going to be fraught with problems.
I've already ensured that as much of the boot sequence as possible is relative (so it can be copied to ADFS by the !BootADFS application) - but setting up Shares correctly will always need absolute paths.

No, not at all - sorry if I gave that impression. I just meant that it might be worth looking into, in case there's a way of changing it (perhaps with an appropriate IfThere) without any other disagreeable effects. If that's not the case then I'm happy to take your word for it (I know absolutely nothing about RO networking).
Adam

This is turning into a discussion which nobody can win, because I can demolish your reasoning in much the same way that you can demolish mine. Fundamentally you are right and I am not wrong

With a real (out-of-the-box) Acorn Risc OS Computer (say, a Risc PC700 running Risc OS 3.6), do the following steps:
1. Open a Task Window (^F12)
2. In the window give Pinboard a relative pathname by typing *pin $.!Boot.choices 100 500
3. Watch as Pinboard accepts the relative Pathname and pins 'choices' to the desktop at position 100 500.
4. Double click on the 'choices' icon to open the directory and see that the relative pathname was accepted and dealt with.
Changing the current directory or the current disk (or even current filing system) after the pinning was done will not affect the pinned icon. It still opens correctly, when double clicked.
Of course, it will also work with an absolute pathname.
Unfortunately trying to demonstrate this on a VirtualRPC-SE build is impossible as the pinboard module is broken - resulting in *pin commands not working correctly with either absolute or relative addresses
-----------------------------------------------------------------
Having said all of that, we are all still left with the fact that the out-of-box build of VirtualRPC-SE does not allow users to easily change the name of the hard disc without a generating a subsequent error. (It can only be done, by manual editing the cfg file before the system is booted for the first time).
Incidently, it is also confusing that the disc which identifies itself as 'HardDisc4' is actually HostFS::0 rather than HostFS::4

HardDisc4 is the default name for the boot drive on many real machines and we have kept this convention to make it easier for users who are familiar with this setup. It's not confusing - what would be confusing would be calling it something different to what a user would expect to see on a real machine.
Anyway I think I am going to declare this discussion closed.