www.virtualacorn.co.uk/forum

Is it possible to rename HardDisc4?
I'm a little reluctant to fiddle with 'Add' or 'Remove' on the options dialogue in case I cause a major problem.
Thought it better to ask first.
Gary

I don't reccomend renaming the harddisc - although you can do it from the HostFS control panel.

What's the reason for that? Is it still the case with VRPC-Adjust?


Ooh, can you give more details?
Thanks,
Adam

You shouldn't rename a harddisc under RISC OS for a number of reasons. Firstly there's a high degree of probability that some things in your boot sequence wimply won't use relative names.
As an example suppose there is a reference to:
HostFS::HardDisc4.$.Printing.!Printers
In the boot sequence - if you rename the harddisc to, for example, Jim.
then the real path to the file would now be:
HostFS::Jim.$.Printing.!Printers
So RISC OS would no longer "find" !Printers and would throw up an error on booting.
If the entire !Boot sequence uses relative names, such as:
<Boot$Dir>.^.Printing.!Printers
then renaming the harddisc shouldn't cause as many problems, although
apps (and the pinboard) may still complain that they can't find things.
You can "rename" the existing HardDisc4 from the HostFS control panel by
making a new HostFS mount that points to the HardDisc4 folder (as seen by Windows) with a new name (for example Jim). You would then
have 2 HostFS mounts that point to the same Windows folder. Removing the one named "HardDisc4" would just leave the one called Jim, which would then become the first drive, and hence the boot drive.
However I really don't reccomend doing this, if you really must and are prepared for the potential problems then firstly back up the file:
C:\Program Files\VirtualAcorn\VRPC-xxx\Models\Arm 7 RISC OS xxx(Jit)\Model.cfg
(where xxx is determined by your version of VirtualAcorn)
So if it all goes wrong you can put things back. Also note that if you do rename the harddisc and it does all go wrong I won't be able to provide any support, I'll simply tell you to put it back!

Oh, OK - so it's not a recommendation related to VRPC then? I'm more than happy to rename my Harddisc - I've done so for the past 10 years so would disagree that it's a problem


Hmm, sounds a bit fiddly - I might just create a seperate mount to hold everything except my Boot sequence, then hide HardDisc4 away inside Minidisc.


Problems related to VRPC or RISC OS?
Cheers,
Adam

Problems related to RISC OS, provided the new HostFS mount is set up correctly (with the same flags as HardDisc4 - Bootable + Show DOS Extensions) then VRPC shouldn't mind, but it's at your own risc

Worked a charm, thanks
Adam

Glad it's working OK, certainly better than my spelling on earlier posts

Sorry to drag up this old thread but I've just been moving my VRPC installation and setting things up again, which included renaming the harddisc. I did get a single "disc not found" error, which I tracked down to the file boot.tasks.AccessSet. This references HostFS, so I suspect it's a VA-created file. Perhaps it could be re-jigged to have a relative file reference?
Cheers,
Adam

The AccessSet file sets up ShareFS drives. So it can't have relative paths it needs to have absolute paths.

Hmmmm. I agree it is far better to quote absolute paths.
But it will work with relative paths.
So, simply having
Share Public
does work with the standard VRPC-SE build as the 'current directory' is set to the root of the boot disc during the boot sequence.

OK - so using relative paths just in the AccessSet file how do you (for example) share multiple folders - or the root of a harddisc?
As far I am aware you can't. Which is why it uses absolute paths, in exactly the same way as a "real" RiscPC would.

The topic under discussion all follows from an original question "Is it possible to rename HardDisc4?"
.... and what a user would need to do to achieve that.
The discussion has made it clear that you do not recommend that - and nobody has disputed that point with you.
However, a second person stated that he had made it all work with one exception
I simply answered his final question, giving a method by which he could eliminate his single remaining error.

I stick to my assertion that relative paths will work. The following just in the AccessSet file (on either VRPC or a Real RiscPC) will share multiple folders and the root of the hard disc.

Share Public
Share Apps -readonly
Share $

However, I remind you that I did say:
Of course, I should also have commented on his "suspicion" that boot.tasks.AccessSet file was a VA-created file. It is not. It is created by the !ShareFS application whether on a Real RiscPC or on VRPC.

Sorry, but I disagree. The AccessSet file must have absolute paths, not relative paths.
The file is created by the !AccessSet application in Networking, it is not created by ShareFS.

One of the fundamental points with the design of filing systems on RiscOS since the early Acorn days and still carried through until today is that file/directory pathnames can always be absolute or relative. This has always applied to both the command line and to properly written desktop applications, and applies to real computers or virtual ones.
VirtualRPC-SE is your system. You have the right to build it how you like; but the !AccessSet application (like every other correctly written application) is based on those early Acorn principles and the AccessSet file does work with properly created relative directory paths (because the *share command will deal correctly with absolute or relative pathnames).
Relative paths beginning with $ are always taken from the root directory of the current disk (no matter what the current directory might be).
However, with your second point you are, of course, quite right:-
"The file is created by the !AccessSet application in Networking, it is not created by ShareFS."
(I did not check my typing. )