DizzyOfCRN wrote:
fat-handler should be fixed to use the serial number provided by the boot block. It may or may not contain a time stamp, but should provide unique serial number.

There might be some other issues in dos.library, specifically something related to the type of the doslist, eg. is it a list for an assignement or to a volume and comparison of labels that don't take that information to the equation.

magorium wrote:
....
Besides that i wanted to thank you for having taken the time to elaborate as that makes things more clear now. (i guess if i was smarter then i could have guessed your underlying idea, but that seemed to not have worked very well for me earlier in the discussion ).

I really would like to agree on that part, but be aware that this not a real solution for those that travel amongst the seas a lot and that not everyone is able to steer along-side the ice-berg (by that i meant have the actual rights to make those changes).

Your solution does not seem to make matters worse as they already are. I had to come to terms that it won't solve certain issues either. (see also later).

Now looking at your idea again and assuming i go along, there is the issue of naming left and which is what i worried about from the start (but your solution does not seems to address, which i assumed wrongly that it would).

You seem to introduce also something anew half way through:
Quote:

That not only forces Aros to boot from a certain device. It also gives the system a hint in what order volumes should be mounted.

As described above, AROS tries to boot from whatever device possible. In that stage i can only assume that the list in ram (as you mentioned it) is already (partial) in place.

It seems undesirable to change entries in that list during boot-time. Especially since it could be that the desired boot-device (whether it is a user installed driver, mount or otherwise) actually relies on the properness of this list. (Since i'm not knowledable enough, please feel free to correct)

One could argue that this would be the user making worng assumptions, but we should be able to rely on something. Just as usual startup-sequence does rely on at least a couple of things.

Say you have a perfectly working system based on your idea, and during boot AROS mounts a network drive. But alas, now that automatic renaming is into place, and in this particular case a pendrive was inserted that conflicts with the mounted name, we have a problem as we can't rely on the configured mountname anymore ?

Which also brings me to something i thought your idea would address, but obviously doesn't (so i am sorry for the confusion that might have brought). If during boot of the startup-sequence there is a check if a certain assign was made and in case not then assign it, that it can conflict with any of the other devices that were mounted. E.g. if i name my fat32 partition libs: i got a problem booting AROS properly.

Not only that, but i if i would leave out the fat driver while booting, the problem re-appears. At least i would assume your idea causes the fat32 LIBS: volume to be renamed (guessing there, so feel free to help me out).

cybergorf wrote:
Quote:

{ snipped }

"And now for something completely different..."

That seams to be way no. 837 to crash Aros.

Sure it seams to be a bug in the same "region" (mounting related), but also could be something in Poseidon alone...

new thread?

cybergorf wrote:
Quote:

magorium wrote:

Yes, but that does not change the fact that the actual real stored in rdb device names differ. What you seem to propose (see, i need to guess again ;-p) is adding an extra layer taking out the actual real device name and mix something together based on the algorythm that you showed.

Although that might be a solution, i find it a rather odd one (but that might be just me).

ok, ok How to implement the desired behavior is already the next question. I think first we need to find a naming police we can agree to and that does improve things.

But to have a look at this 2nd step anyway:

There is the volumenode structure in ram, that should store all kind of information like physical device, no. of blocks, size of blocks and finally the label!
So e.g. wanderer or shell don't care what is written in the rdb once the device is mounted.

Our fake-label is written in that structure during the mount process instead of the real label.

We can agree on "not booting at all" prevents all problems

We can also agree, that there should be no duplicate labels in the standard Aros setup. Meaning we are not aiming to provide a solution to boot into a system, with a lot of label-duplication as default option!

Volumes used by a user on a daily basis should be given unique labels. Once identified a duplication the volume should be relabeled permanently by the user, to avoid further conflicts!

That not only forces Aros to boot from a certain device. It also gives the system a hint in what order volumes should be mounted.

Kalamatee wrote:

IMHO -:

A> you need to check exactly how its handled on AmigaOS (what naming convention is used), otherwise scripts and such will be incompatible.
B> you need to find out where exactly this happens on AmigaOS and duplicate the behaviour. I suspect it is when the doslist entry is registered.

cybergorf wrote:
Quote:

magorium wrote:

Yes, but that does not change the fact that the actual real stored in rdb device names differ. What you seem to propose (see, i need to guess again ;-p) is adding an extra layer taking out the actual real device name and mix something together based on the algorythm that you showed.

Although that might be a solution, i find it a rather odd one (but that might be just me).

ok, ok How to implement the desired behavior is already the next question. I think first we need to find a naming police we can agree to and that does improve things.

But to have a look at this 2nd step anyway:

There is the volumenode structure in ram, that should store all kind of information like physical device, no. of blocks, size of blocks and finally the label!
So e.g. wanderer or shell don't care what is written in the rdb once the device is mounted.
Our fake-label is written in that structure during the mount process instead of the real label.

Now (i guess as that is the software telling me) poseidon goes haywire, as it seems it is not capable of determining the different pendrives from eachother. It attaches my freshly inserted pendrive but at the same time throws out my earlier attached devices, including mouse and keyboard.

That has nothing todo with a renaming of volume names and/or device names, but seems to be caused by a issue that lies underneath all of that. Mind, that i can only guess here, as i am not able to debug the issue myself. When i use a different brand/model pendrive in the same situation then everything seems to work for me as expected.

magorium wrote:

Yes, but that does not change the fact that the actual real stored in rdb device names differ. What you seem to propose (see, i need to guess again ;-p) is adding an extra layer taking out the actual real device name and mix something together based on the algorythm that you showed.

Although that might be a solution, i find it a rather odd one (but that might be just me).