AmigaOS 3.2.3 update available

[nbache]

One obvious reason is to get around "naive" software which doesn't work correctly with paths containing spaces.

I am a beta tester (of OS4), so I take the opposite stand - I often specifically test things against the RAM Disk to make sure I catch anything of that kind :-).

Best regards,

Niels

[F0LLETT]

One obvious reason is to get around "naive" software which doesn't work correctly with paths containing spaces.

I am a beta tester (of OS4), so I take the opposite stand - I often specifically test things against the RAM Disk to make sure I catch anything of that kind :-).

Best regards,

Niels

Surely logic would dictate you use RAM: instead of RAM DISK:, to avoid such issues. Save messing messing around and nothing has to be done.

[Munchkin]

Surely logic would dictate you use RAM: instead of RAM DISK:, to avoid such issues. Save messing messing around and nothing has to be done.

Precisely my thought. Ram: has always worked as well so I don't see any problem here.

[nbache]

I have seen stuff insisting on using the volume name instead of the device name, so that even if you had specified RAM:, it would translate it to "RAM Disk:".

Best regards,

Niels

[F0LLETT]

I have seen stuff insisting on using the volume name instead of the device name, so that even if you had specified RAM:, it would translate it to "RAM Disk:".

Best regards,

Niels

They should be shot. Thats like people using hard coded paths to say drive name:location of program. Instead of using sys:location of program.
That way, regardless of drive name, everything works.

[TribbleSmasher]

They should be shot. Thats like people using hard coded paths to say drive name:location of program. Instead of using sys:location of program.
That way, regardless of drive name, everything works.

All preferences programs do expand any path to the real name, even Assigns. And yes, i hate it.

[chris]

All preferences programs do expand any path to the real name, even Assigns. And yes, i hate it.

The reason, IIRC, is twofold.

1. If you Lock a path and then query that Lock for the path, the OS will give you the full path containing the volume name (I have a feeling some changes were made wrt this in OS4, but assigns will still be expanded)

2. You can't guarantee that the volume inserted in a device will stay the same, so using the volume name allows the OS to request the correct disk. (less of an issue these days, but historically essential)

[nbache]

All preferences programs do expand any path to the real name, even Assigns. And yes, i hate it.

I believe we did get rid of all those situations in prefs programs in OS4; the last one was WBPattern, and I think that's already 5-10 years ago.

I'd suggest reporting them as bugs also in 3.x.

Best regards,

Niels

[ZXDunny]

I'd suggest reporting them as bugs also in 3.x.

Assuming files are on DF0: instead of Update3.2.3: is probably going to come with a lot of issues.

[TribbleSmasher]

But when i want to use a generic installation and my wallpapers are on WBGFX: (SYS:Prefs/Backdrops/) Assign, i don't want a fuckup just because the boot partition is not called Workbench or System or MacintoshHD....

[nbache]

Assuming files are on DF0: instead of Update3.2.3: is probably going to come with a lot of issues.

Yeah, but I'm talking about the situation where you have saved a preference as default, e.g. (for WBPattern) with a reference to a backdrop located in SYS:Prefs/Presets/<something>/..., then you don't want "SYS:" to be converted and saved as e.g. "Workbench:" in that path, because if you copy your prefs to another boot partition, you'd have to go through them all and correct them to whatever you called that partition.

That's what we got fixed in OS4.

Best regards,

Niels

[polyp2000]

Anyone got a list of the full changeset / improvements / etc - i cant find them anywhere , and if the register article is anything to go by PiStorm32 would be officially supported.....

[F0LLETT]

Anyone got a list of the full changeset / improvements / etc - i cant find them anywhere , and if the register article is anything to go by PiStorm32 would be officially supported.....

Works fine on PS32. Updated and all is working great.

[TribbleSmasher]

Anyone got a list of the full changeset / improvements / etc - i cant find them anywhere , .....

the changelogs for each component are located in the ReleaseNotes folder.
I have compiled a one-file-amigaguide and attached it here
https://forum.amiga.org/index.php?topic=77131.msg862940#msg862940

be aware that all the logs have the newest changes at the end, so you'd need to scroll down each time to see if there are indeed fixes et.

[Tumbleweed]

Thanks Follett. I rebuilt the ROM and used exec from the modules.adf - works fine now.

Weed.

[polyp2000]

Great news that it works, but it seems like websites claiming it has specific updates for PiStorm are talking out of their proverbial . That would be big news - but its a lie as there is no mention of it in that release notes file.