Assign a volume name to another volume name

[Leon Besson]

Hi Bromigos!

I’m currently using A Jaz Drive (2GB) to backup my AmigaOS files which is also bootable.
At the moment I have the main AmigaOS volume set as OS39 and the Jaz Cassette labelled up as OS39-BUP.

Now I’m looking into a way to setup an Assign in my startup-sequence which is on the lines of;

If VolumeName=OS39-BUP:
then
Assign OS39: OS39-BUP:
EndIf

That way I can keep the Assign on my main AmigaOS and if I boot from Jaz it will auto assign the volume correctly.

Is this doable?

Thanks Mangs!

[DisasterIncarna]

maybe just do

Assign OS39: IS39-BUP: >NIL:

that way if OS39 already exists the assign will fail, >NIL: will suppress the error message and your startup-sequence will carry on as usual, however if this was a boot from OS39-BUP: then OS39 would not exist meaning the assign would work and OS39-BUP: would also successfully be refered to as OS39:

The If Exists stuff here isnt really needed, i do the same thing for my emulated Amiga setups, i have a part that does exactly what i listed above but for

RUN >NIL: Assign Games: SYS:Games >NIL:
RUN >NIL: Assign Music: SYS:Music >NIL:

I have actual Devices filled with LOTS of music/games, but if theres not enough room to copy all of that into say an emulator for my Pi400 or PS Vita, then i have folders in SYS: also called Games and Music, and they contain a much smaller selection, if the Games: and Music: devices arent setup then assign just creates the equivalent in my 2 folders in SYS: and all is well, if the devices do exist then the assigns just silently fail and carry on normally.

Cant remember if the FailAt value needs to be changed or not, but using RUN >NIL: at the start can get past that small issue.

[Leon Besson]

Originally Posted by DisasterIncarna

maybe just do

Assign OS39: IS39-BUP: >NIL:

that way if OS39 already exists the assign will fail, >NIL: will suppress the error message and your startup-sequence will carry on as usual, however if this was a boot from OS39-BUP: then OS39 would not exist meaning the assign would work and OS39-BUP: would also successfully be refered to as OS39:

The If Exists stuff here isnt really needed, i do the same thing for my emulated Amiga setups, i have a part that does exactly what i listed above but for

RUN >NIL: Assign Games: SYS:Games >NIL:
RUN >NIL: Assign Music: SYS:Music >NIL:

I have actual Devices filled with LOTS of music/games, but if theres not enough room to copy all of that into say an emulator for my Pi400 or PS Vita, then i have folders in SYS: also called Games and Music, and they contain a much smaller selection, if the Games: and Music: devices arent setup then assign just creates the equivalent in my 2 folders in SYS: and all is well, if the devices do exist then the assigns just silently fail and carry on normally.

Cant remember if the FailAt value needs to be changed or not, but using RUN >NIL: at the start can get past that small issue.

Thanks Mang!

Will give it a go

[Leon Besson]

Originally Posted by DisasterIncarna

maybe just do

Assign OS39: IS39-BUP: >NIL:

that way if OS39 already exists the assign will fail, >NIL: will suppress the error message and your startup-sequence will carry on as usual, however if this was a boot from OS39-BUP: then OS39 would not exist meaning the assign would work and OS39-BUP: would also successfully be refered to as OS39:

The If Exists stuff here isnt really needed, i do the same thing for my emulated Amiga setups, i have a part that does exactly what i listed above but for

RUN >NIL: Assign Games: SYS:Games >NIL:
RUN >NIL: Assign Music: SYS:Music >NIL:

I have actual Devices filled with LOTS of music/games, but if theres not enough room to copy all of that into say an emulator for my Pi400 or PS Vita, then i have folders in SYS: also called Games and Music, and they contain a much smaller selection, if the Games: and Music: devices arent setup then assign just creates the equivalent in my 2 folders in SYS: and all is well, if the devices do exist then the assigns just silently fail and carry on normally.

Cant remember if the FailAt value needs to be changed or not, but using RUN >NIL: at the start can get past that small issue.

Soooo….Tried that above and on startup I’m getting requests to insert the volume OS39-BUP

If I use the RUN command as described above, I still get the messages but then my RTG stops working and I go into standard Amiga workbench graphics mode.

I can cancel this, but it’s something I’m trying to avoid

Any other ideas? Should I be including a failAT somewhere?

Thanks Bromigos!

[indigolemon]

Not all my own work, based on code someone else wrote that I've used myself to check if a volume exists:

assign >NIL: AmigaOS: exists
if not warn
echo "AmigaOS: exists"
else
echo "AmigaOS: unavailable"
endif

A working example for your use case should be:

assign >NIL: OS39: exists
if warn
Assign OS39: OS39-BUP: >NIL:
endif

[Leon Besson]

Originally Posted by indigolemon

Not all my own work, based on code someone else wrote that I've used myself to check if a volume exists:

assign >NIL: AmigaOS: exists
if not warn
echo "AmigaOS: exists"
else
echo "AmigaOS: unavailable"
endif

A working example for your use case should be:

assign >NIL: OS39: exists
if warn
Assign OS39: OS39-BUP: >NIL:
endif

Thanks!

[DisasterIncarna]

Originally Posted by Leon Besson

Soooo….Tried that above and on startup I’m getting requests to insert the volume OS39-BUP

If I use the RUN command as described above, I still get the messages but then my RTG stops working and I go into standard Amiga workbench graphics mode.

I can cancel this, but it’s something I’m trying to avoid

Any other ideas? Should I be including a failAT somewhere?

Thanks Bromigos!

Try changing

Assign OS39: IS39-BUP: >NIL:

to

Assign OS39: IS39-BUP: DEFER >NIL:

The assign should again fail (silently i hope) if OS39 exists, but this time will set the assign as Deferred, so it wont become active unless OS39 is indeed successfully assigned due to OS39 not already existing, and only THEN will IS39-BUP become used when the new assign is referenced/used, the assign will remain hidden/unused until it is accessed, this should avoid a requester (at least it is on OS3.2 atm).

Btw, when you said "boot from the jaz drive" and your booting from it, does that mean you are disabling the OS39 boot drive? or literally just booting from the jaz with OS39 still active? Because the above assumes OS39 does not exist/was disabled.

If you arent disabling it, then that would be better cured by finding any reference on your OS39 to OS39: and changing everything to SYS: that way it wouldnt matter if you booted from OS39 or the Jaz, SYS: is literally a reference to whatever you booted from.

I change a lot of my programs/preferences to use SYS: instead of the drive/device name, its just easier for stuff like this and when copying installations in emulators

[Leon Besson]

Originally Posted by DisasterIncarna

Try changing

Assign OS39: IS39-BUP: >NIL:

to

Assign OS39: IS39-BUP: DEFER >NIL:

The assign should again fail (silently i hope) if OS39 exists, but this time will set the assign as Deferred, so it wont become active unless OS39 is indeed successfully assigned due to OS39 not already existing, and only THEN will IS39-BUP become used when the new assign is referenced/used, the assign will remain hidden/unused until it is accessed, this should avoid a requester (at least it is on OS3.2 atm).

Btw, when you said "boot from the jaz drive" and your booting from it, does that mean you are disabling the OS39 boot drive? or literally just booting from the jaz with OS39 still active? Because the above assumes OS39 does not exist/was disabled.

If you arent disabling it, then that would be better cured by finding any reference on your OS39 to OS39: and changing everything to SYS: that way it wouldnt matter if you booted from OS39 or the Jaz, SYS: is literally a reference to whatever you booted from.

I change a lot of my programs/preferences to use SYS: instead of the drive/device name, its just easier for stuff like this and when copying installations in emulators

The use of the Jazz drive is when I have a catastrophic failure and need to restore the System files back to a clean SD card.
Unfortunately I have some old associates that use the actual volume name such as AmiDock and other programs which some how have attached this too. Yes I know the standard given name should be Sys: But it’s how it is at the moment.

Will try both methods and report back.

Thanks for the replies

[AMIGASYSTEM]

If I understand correctly what you want to do, try this or vice versa:

Path ADD OS39-BUP: OS39: >NIL:

[indigolemon]

Originally Posted by AMIGASYSTEM

If I understand correctly what you want to do, try this or vice versa:

Path ADD OS39-BUP: OS39: >NIL:

Path definitely isn't the right tool here - it's used to set/amend the search path that AmigaDOS follows when looking for a command or program to execute, not assign a volume name if required.

See http://jaruzel.com/amiga/amiga-os-co...help/path.html

[thomas]

Try

Assign >NIL: OS39: SYS:

If you boot from OS39-BUP it will work, if you boot from OS39 it will fail but continue.

[DisasterIncarna]

yeah that look like a way better version of what i was looking for

[Leon Besson]

So at the moment I’m using the DEFER option which appears to do what I want it to do. But will have a look at the other suggestions as well.

Thanks Bromigos!

[AMIGASYSTEM]

Originally Posted by indigolemon

Path definitely isn't the right tool here - it's used to set/amend the search path that AmigaDOS follows when looking for a command or program to execute, not assign a volume name if required

It depends, I use that command on my AROS One Distribution, I will give you an example to make my point:

If I set an Icon to a program located in DH0:Extras, if someone moves the Extras folder to DH1 (provided by InstallAROS), the program will no longer be found.

With my command the Extras folder will be found even if moved to DH1:Extras

[haps]

Originally Posted by AMIGASYSTEM

If I understand correctly what you want to do, try this or vice versa:

Path ADD OS39-BUP: OS39: >NIL:

Originally Posted by AMIGASYSTEM

It depends, I use that command on my AROS One Distribution, I will give you an example to make my point:

If I set an Icon to a program located in DH0:Extras, if someone moves the Extras folder to DH1 (provided by InstallAROS), the program will no longer be found.

With my command the Extras folder will be found even if moved to DH1:Extras

So in other words you do not understand correctly. (or vise versa)

[AMIGASYSTEM]

Excuse me but I didn't understand anything about what you wrote !

[Leon Besson]

I feel a cleaning job coming on

To keep this post on track, the “Defer” option seems to be working out for me

Thanks to those Bromigos! Who knowledge shared

[haps]

Originally Posted by AMIGASYSTEM

Excuse me but I didn't understand anything about what you wrote !

As indigolemon said, this issue had nothing to do with $PATH.

[malko]

If this can be of any help : https://eab.abime.net/showthread.php?t=108682

[DisasterIncarna]

Originally Posted by Boing-Ball

Does anyone know if the defer syntax still works or has changed in 3.2.2.1?
Just tried it and got an error. Tried on 3.1.4 and it works.

im still using multiple DEFER's in my startup-sequence and user-startup, no issues i can see.