No that is not neccesary


however, you had a problem with System: this happen I beleive when Assign is trying to delete/remove an already existing Assign that can't be removed

for example Assign DH0: -> can't cancel DH0

Strange though that you can't cancel system: except if you have a storage that by default is named System: then I understand it.

I beleive that (but have not investigated to deep) that I remember that the first drive DH0 many times where called System: this could therefore be an old "relic" that lives on.

Thus the sys drive in AROS is called AROS: an assign like Assign System: AROS:|SYS:|DH0: could be kind of true, but if you name your sys: drive like SYSTEM: then there would be failure

Assign System: AROS: -> can't cancel System:


but I guess you already now that, but just in case...

Actually and afaik, the only thing that is set in stone is that amiga/AROS boot device is named SYS:

The rest can be based on that, but no matter what you do the device you boot from will be named SYS:, whatever what the device will be (in theory you can have multiple devices to boot from and select which one from early boot menu, or otherwise e.g. by removing/disabling drives or change boot priority).

As long as you circumvent using the labeled name of the device that was booted from, you're pretty safe with whatever you do inside scripts and in theory that should be enough to do whatever trickery you want to.

In case some of the scripts in icaros is causing issues, can be improved or otherwise then i'm sure that any fix is appreciated. I can understand that paolo does not have the time to spend too much time on such issues, as things work as expected for what it was created/invented for.

For sure, i'll leave this topic alone now, in case that is your wish.

Well, as I somewhat tried to explain after the "scenario" was that I realized that the idea was quite "overworked"...


Actually I just got surprised, when I simply relabeled the SYS: drive, that it refused to to boot without complaining...

It is - I must say NOT so important, as I said i was surprised and my initial respons was "that should not be", that was the reason I addressed this question to begin with.

Then Paolone used the for me magical words "you have to live with that" wich I translated to: it can't be changed, undoable... I had to some extent proof it to not be completely true, it is a bad habbit I know, but I do not beleive in: it can't be done.

It is my fault, not Paolones nor you or anyone else if someone should read what I say different to what I mean.

//So it was that simple, nothing more.

Quote:
Well, yes i was

Please, don't worry too much

I clearly understand why you want things to be more flexible, just not why you think it is not so at this moment.

You can change the myvar variable to wherever you want it to be in order to change locations for example for MyWorkSpace.

The specific scenario that you mentioned might perhaps not happen often, but i do feel the pain whenever i insert another pendrive with AROS installed on it.

My AROS work-machine does not use dh0: / du0: and whatmore. Instead i use a complete custom setup so that i know for sure names can't clash.

If not mistaken then improvements where made to AROS, so that at least it is possible to access the second device using the same names -> something that failed miserably in the past, confusing AROS itself.

fwiw: I've seen that somewhere in the past there was code/scripts that has some form of multi-users support (so also multiple/individual workspaces), but i don't believe that was actively maintained. I don't even remember if that was an Icaros and/or AROS feature.

Just wanted to say, that things are pretty flexible already, and yes it requires some research and modifications if you want to customize things exactly the way you want them to be.

It might proof more interesting to show _exactly_ what you think needs to be done, so Paolo is able to see what the pro's and con's are of such a solution (that you think is necessary).

My own personal opinion (which i did express), is not important in this matter.

Hmmm?

Magorium

I do not know if you are addressing me...

In case that you are then

I will explain the scenario...

Lets assume that not only MYPATH is a flaw, lets assume that there is more apps and settings elsewhere unknown for the moment, whatif I really need to change my disk name to AROS1:

Then suddenly there will be an issue, an issue that might be easily fixed by making an assign by myself, in user-startup...

However lets assume there is a person relatively "new" to AmigaOS he has tested a version and now updated (in VBox) he mount the old AROS sys drive and now see two identical AROS and he do not know which is which...

He close down the VM, disconnect the older one, restart and in Magellan rightclick drive labeled AROS: and rename it to uhmm AROS2: (imagine that he does not know AmigaDOS).

On next boot with the old AROS named AROS: some things points to the old system - not good, anyway he copy the files he need to the new system close down remove old drive and reboot, now he got errors... because AROS: is nowhere to be found.

Yea, you right... it is a big fuzz, it propably will not happen, and even if it does, it is just one (test) user.

please forget this thread.

to much work for nothing!

I am completely covered in riddles, sorry. I simply don't understand what more there is to improve/customize.

so:

With an installation, it is mostly so that the MyPath ends up on DH0: or DH1 (at least when it comes to HD installs)

Could you perhaps (as a workaround) detect what drive the MyWotkSpace ends up on and use DH0: DH1: etc in that scenario? (not only talking about myWorkSpace)

because when you after an installation manually "move" MyWorkSpace to a different "drive" you are more likely to "remember" what would get affected, but if you have several paths that relies on AROS: for example... Then in the worst case scenario, many things may brake...

or create yet another envarc variable that upon startup has a key value pair like:
AROS=DH0: ;or whatever
WORK=
EXTRAS=

this are created at installation and are not supposed to be changed... If an Assign Exists check is done at every startup and the specific Assign is missing because of a relabel or whatever, that script could reAssign AROS: to DH0: even if the drive is named differently.

well a bit blurry ideas but I hope you follow the thought though.

Quote:

Ok, I've looked what's wrong and the simple answer is: you have to live with that, and change the value of MYPATH according to any "relabel" of the system partition.

MYPATH is set by aros-post-install script at the end of installation onto the hard drive, either in the sys: or work: partition (if it exists) following the same volume where the EXTRAS directory is placed. This means that it might take the "AROS", "AROS Live Drive", "Work" or any other correct value.

If you manually make changes like the boot partition, you should change the value of MYPATH according to your changes. A solution for the issue might be a check of the effective exsistence of the path ${icaros/MYPATH}:MyWorkspace which will ask the user what to do. This might be implemented in S:myworkspace-startup.

fwiw: i tried to run icaros hosted, and ran into something similar. Dopus starts with open shell window telling "Can't cancel system:"

Therefor, i started hunting down system: related material on the experimental archive (boot only, although lua and mui unpacked and checked as well), and quite honestly i wasn't able to find so many.

- ScalOS (sys:Prefs\Env-Archive\Scalos\Menu13.prefs), apparently something is configured to use System:System/Find (probably not important)
- Amistart (sys:System\AmiStart\AmiStart), seems to have system: hardcoded in there (might perhaps cause issues, dunno for sure).
- Dopus (sys:Utilities\DOpus\S\DirectoryOpus.CFG), there seems to be something 'hard' configured to system: in there (probably a assign button, if so then not important).

So, i was actually unable to solve my initial encountered problem, but thought perhaps this can help you pinpoint.

red 1: additionally:
- sys:Prefs\Theme is using AROS:
- Dopus5 default environment file (68k + i386) is using AROS: assignment

Absolutely!