Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

Irritating bug of the month - November

Last updated on 3 months ago

Poll: IBOTM - November

    #105 (DiskInfo showing OFS instead of FAT) [0/5]0 %
    #100 (Errors while moving files to Storage or WBStartup) [0/5]0 %
    #91 (Wrong parsing of boot parameters in Prefs/Boot) [0/5]0 %
    #74 (Contrib LHA has issues when used from ZuneARC) [1/5]20 %
    #70 (pc105_i and pc105_d keymap is corrupt) [0/5]0 %
    #64 (Wanderer: properly run tools with CLI tooltype) [2/5]40 %
    #49 (Unreadable names with DiskImageGUI and ISO9660 images) [0/5]0 %
    #47 (Wanderer: single icon without the associated file cannot be deleted) [1/5]20 %
    #43 (Rename issues with fat-handler) [0/5]0 %
    #42 (Regression: Volume Information Window) [1/5]20 %
D
deadwoodAROS Dev
Posted 3 months ago
So this was observed only under 68K Wanderer? This will make it harder. Do you have a tool that has these problems by runs under x86 AROS?
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
At the moment, I don't recall an AROS Application that from Shell does not detect the config file in its path.

But regarding the Shell, there is a more important Bug, which I had reported in the past and concerned "UHCTools"

http://archives.a...6-aros.lha

To install UHCTools (Cross-platform Installer Script) you need LHA in 'C' and an Internet connection

The installation will add commands in the user-startup, create the folder SYS:UHC where it will unpack the downloaded data, it will also create in the Env-Archive a UHC folder where some scripts will be copied, also in the Env-Archive it will create and a preferences file (UHCBIN)

UHCTools problems (see screenshot):
- User-Startup commands are not supported (even if you use a manual command, nothing changes)
- If you run one of the scripts found in "UHC:S" from a Shell, the System hangs, and then crashes VmWare

Did the same operation on a full OS 3.1 and everything worked fine, see screenshot
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
For the UHCTools, I created an bug report here: https://github.co...issues/112

Getting back to TKUnpacker, can you prepare me a zip of AROS with it installed, some example archive configured to use it and it failing like you described in initial report. I want to avoid situation where I do something different than you did and arrive at different behavior.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
Ok, in the meantime I noticed that TKUnpacker now works on AROS 68k, however a small problem remains on AROS 68k.

In the attached archive there is TKUnpacker and two LHA and ZIP Archives with icons configured to be unpacked automatically by TKUnpacker, also there is the Env-Archive folder containing the config file (TKUnpacker.config)

- On OS3 if you run these icons associated with the archives, the file 'TKUnpacker.config' will immediately be created in the Env-Archive directory, and the archive will immediately be unpacked to the path set in the requestfile.

- On AROS One 68k (can't remember if AROS 68k is your old build) if you run the Icons associated with the archives you will get the error 'Unable to read file' "TKUnpacker.config"
This is solved by "manually" copying the file "TKUnpacker.config" to the Env-Archive, and everything will work

- On the Latest AROS 68k Build of "aros.sourceforge.io" dated 16 October 2023, after copying the config file, you have to reboot the system otherwise the file "TKUnpacker.config" will not be found
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
Ok, I check how this behaves on my build.

With regards to last point, I'd assume TKUnpacker reads config from ENV:. Try copying TKUnpacker.config to RAM:ENV and see if it works without reboot.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
It works if I copy TKUnpacker.config to RAM:ENV, which is what happens when you do a reboot !

As mentioned in previous versions of AROS 68k there was no need to reboot!
D
deadwoodAROS Dev
Posted 3 months ago
That's strange BTH. I don't recall anything that would copy the files automatically from ENVARC: to ENV:

Even the installation instruction for TKUnpacker says explicitly:

1. move "TKUnpacker.config" to ENVARC:
2. move "TKUnpacker.config" to ENV: or reboot before using unpacker
3. move the executable "TKUnpacker" wherever you want, e.g. C: or SYS:Tools
D
deadwoodAROS Dev
Posted 3 months ago
Can you also provide me the lha and zip unpacker that are needed by TKUpacker?
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago

deadwood wrote:

@deadwood - Can you also provide me the lha and zip unpacker that are needed by TKUpacker?

On AROS One 68k I only use native AROS 68k software, the LHA and ZIP commands are those present in the Contrib (aros.sourceforge.io),
enclose all the archives present in the contib,

Riguardo TKUnpacker.config hai ragione, non so perchè questa mattina su OS3 TKUnpacker funzionava senza TKUnpacker.config, probably forgot to delete it somewhere! !
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
Ah ok, I didn't know. I will then use the ones from build.

In the meantime I checked TKUpacker under OS3.1 and it does not create TKUpacker.config. It shows the same error as on AROS 68k, see screen shot.
You do not have access to view attachments
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
Yes I had checked too, this morning I was probably still asleep and did not see the file Smile
D
deadwoodAROS Dev
Posted 3 months ago
Ok, I was able to unpack the first Archive under AROS and OS3.1 when not adding CLI tooltype. So in such case program and system behaves as intended.

Adding CLI tooltype has a different effect on AROS and OS3.1. On AROS it make the program run from shell without any arguments so it displays requester for selecting source archive. On OS 3.1 it actually makes the archive be considered a program and execute command window is opened. See screenshots. In both cases behavior is different than without CLI and different that what you shown on screenshot of AfAOS in the original thread (but that's not clean OS 3.1 right)?

The "Shell" option seems to be a different thing than CLI tooltype. I will do some further investigation on how CLI option behaves under Workbench 3.1.
You do not have access to view attachments
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
AfAOS is based on OS 3.9 BB4

On OS3.9 there is a gadget in the Tooltypes that allows you to start a program from Shell without the Command Prompt request

If you look at this Icon saved on OS 3.9, you will notice that in the tooltypes, in addition to CLI there is also DONOTPROMPT.

CLI and DONOTPROMPT on AROS x86/68k is recognised and works well, I use it often on AROS One x86, on OS3.1 however DONOTPROMPT is not recognised, so it is ignored.

On OS3.9, in the CLI tooltypes, DONOTPROMPT and DONOTWAIT "are hidden" (are the gadgets that store them in the tooltypes), if you add them manually, they will be seen, but will only be duplicated
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
Can you share with me this Archive.lha icon with "Shell" set in OS3.9?

It looks like OS3.9 extended the logic on how this should be handled. Can you check the version of workbench.library that is present on OS3.9/AfaOS?
D
deadwoodAROS Dev
Posted 3 months ago
@AMIGASYSTEM

Actually you found a 14 years old regression! I checked the codes and indeed before 2009 Wanderer could run CLI programs with an argument so it behave like OS3.9.

Here is fixed workbench.library:

https://axrt.org/development/workbench.library-45.4.zip

Please let me know if it works for you!

If you use IconX, please also check if it still works as expected after installing this workbench.library.
Edited by deadwood on 22-11-2023 12:58, 3 months ago
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago

deadwood wrote:

@deadwood - Can you share with me this Archive.lha icon with "Shell" set in OS3.9?

It looks like OS3.9 extended the logic on how this should be handled. Can you check the version of workbench.library that is present on OS3.9/AfaOS?


There are numerous versions of Workbench.library, some have bugs, however all Workbench.library OS 3.9 has those functions:

OS 3.9 = workbench.library v45.102
OS 3.9 BB1 = workbench.library v45.127
OS 3.9 BB2 = workbench.library v45.127
OS 3.9 BB3/4 = workbench.library v45.138
OS 3.9 BB4 AfA One = workbench.library v45.132 (sembra la migliore)

I enclose the saved icons on OS 3.9
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
Thanks - so they are all newer than v40 found in OS3.1
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
Yes most recent, I installed 'workbench.library-45.4.zip' and a conflict arose with other 'GURU' libraries. , see screenshot
You do not have access to view attachments
D
deadwoodAROS Dev
Posted 3 months ago
Did you also install stdlib.library that was in the zip file?
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 3 months ago
Yes I also copied the stdlib.library, even on AROS One x86 I got the same GURU!
You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot edit the poll in this discussion thread.
You cannot vote on the poll in this discussion thread.
You cannot upload attachments in this forum.
You cannot download attachments in this forum.
Users who participated in discussion: magorium, deadwood, AMIGASYSTEM, Amiwell79, miker1264
Sign In
Not a member yet? Click here to register.
Forgot Password?
Users Online Now
Guests Online 7
Members Online 0

Total Members: 214
Newest Member: Khadas
Member Polls
Should AROSWorld continue with AROS-Exec files (SMF based)?
Yes44 %
44% [12 Votes]
No26 %
26% [7 Votes]
Not sure30 %
30% [8 Votes]