Need Feedback for (wip) UHC-GUI

[Swe_Kryten2x4b]

Originally Posted by DisasterIncarna

if it doesnt fit, which is likely, try clicking the entry and look at the info bar at the bottom, that uses a proportional font and should squash more text into it.

I assume you mean what is highlighted in this screenshot? Yes, that works perfectly.

[EctoOne]

Have you added some code that tries to CD somewhere? I noticed that my disk can't start the GUI anymore when I replace the old Exe with the new one from the first page nor the one from the latest test version. It is complaining about a redirection file or something like that. And I couldn't spot anything weird with snoopdos.

[DisasterIncarna]

redirection error? rather than redirect to T: as your kinda supposed to do, i bypassed that incase someone had T: set to a HD/Disk and i specifically redirect to RAM:T/ so at a guess if RAM:T isnt accessible it would fail, tho i also have code that adds RAM:T if it doesnt exist, so not sure what else could fail redirection wise.

And nope, zero code was altered other than adding the new site support, also i cant do CD's at all, remember the program isnt a script, i can only execute 1 command at a time which again is why i tend to use specific full paths, if i were to execute a "CD" then something else it would be like 2 seperate scripts executing their own thing, the second command wouldnt inherit anything from the first so me using "CD" isnt viable.

Any CD'ing or otherwise would be done by the UHC-Tools scripts, they are what i execute, then they take over.

[EctoOne]

My mistake. I didn't replace the old Exe, I replaced my launch script. It's still working fine.

[DisasterIncarna]

[EctoOne]

Here is probably the final release of the disk. I fixed some checks in the launch scripts and added a Download section to the guide where I've put some programs/libraries that can be downloaded with a simple click.

I have included a HDinstall script, but it is not embedded in the installation script. I want to encourage anyone to do a proper installation of UHC and the other stuff, to avoid that problems are reported which are caused by the method the disk has to use. HD installation is pretty easy though, just copy at least LhA and System to your Boot Disk C: directory. Although LhA might be enough, since UHC-GUI will download System anyway. Then drag and drop the UHC icon from the disk to wherever you want. Doing that with MTool won't quite work. The included prefs file is set to use files from the disk. Which means MTool also needs a proper installation or replacement.

Again, rename UHC-Disk.zip to UHC-Disk.adf

[DisasterIncarna]

would it be any use if the GUI added LHA to its list of "things to install for you" if it doesnt exist in C: just like the System command?

[EctoOne]

For the disk not really, because I need LhA before I even get to the GUI.
I just thought of why not download UHC if it can't be found, but I forgot that you need AGET for that.
So, I don't think it is necessary but if you want to add it, go for it. But remember that you probably also need to test the CPU for the appropriate version of LhA. I don't know if it is worth adding it.

[patrik]

Originally Posted by DisasterIncarna

As an example, try TURRANSEARCH SIM CITY, then TURRANEXTRACT 0, or just type SIM CITY into the GUI for Turran FTP, it will list a lot and if you look at the first entry, the filename has + symbols, square brackets [], loads of spaces in it, and the whole thing kinda just facemelts at the present with a filename like that, this will no doubt get a fix later, just do periodic checks for updates to UHC-TOOLS via the GUI or type "UHCUPDATE" in a shell window.

Please give it a try now. Will now escape AmigaDOS pattern characters in the filenames when passing them to commands which will treat them as such patterns - like for example lha and delete.

Be aware that veeeery long filenames might cause issues with the filesystem where T: resides, which is where the files are downloaded by default by uhcextract. You might want/need to set UHC/TEMPDIR to somewhere on a filesystem which can handle the filenames.

[DisasterIncarna]

works perfectly on OS3.2.x, and as you said it fails spectacularly on OS3.1 due to long filenames, OS3.2.x has an option in "Workbench" prefs to set max filename length, OS3.1 does not, unless there is a tool to fudge the same behaviour, then perhaps i could get the GUI to inform the user of the situation and perhaps offer up some hack/tool from somewhere that fixes it.

That or possibly temporarily mount a ramdrive which uses PFS3 or similar which does have long filename support.

Ooooooooor, perhaps the uhc script, specifically for turran's ftp could detect the version of workbench and if using OS 3.0/3.1 then trim the filename length while retaining the file extension? I think OS3.1.4 etc support long filenames along ofc with OS3.2?

[patrik]

I think that workbench setting is just a limit for how long filenames workbench itself will show and create, nothing that the filesystems themselves care about.

The problem in 3.1 is the ramdrive handler itself. I even saw a garbled filename in T: when testing under 3.1, so apparently it is not even truncating the file names, but just going bananas. Would be interesting to know what it’s safe limit is.

If you “setenv UHC/TEMPDIR MyPFSDrive:” you can just redirect the tempdir UHC tools uses to a PFS partition.

[EctoOne]

I just noticed the long filename issue also for whdownload. Something like EyeOfTheBeholder2_v1.1_De_0681.lha gets cut off.

[patrik]

Originally Posted by EctoOne

I just noticed the long filename issue also for whdownload. Something like EyeOfTheBeholder2_v1.1_De_0681.lha gets cut off.

Got a few questions:
1. Was this with whdownextract or whdownget?
2. What was the destination and which filesystem was that running?
3. Which OS version?
4. How did the filename look after it was truncated?

[EctoOne]

Originally Posted by patrik

Got a few questions:
1. Was this with whdownextract or whdownget?
2. What was the destination and which filesystem was that running?
3. Which OS version?
4. How did the filename look after it was truncated?

1. whdownget. whdownextract still worked
2. Ram: OFS and/or SYS: DC-FFS
3. 3.1
4. EyeOfTheBeholder2_v1.1_De_0681

[spotUP]

Double clicking a file in the list to download would be nice.
Viewing collys from asciiarena directly would be nice.

[patrik]

Originally Posted by EctoOne

1. whdownget. whdownextract still worked
2. Ram: OFS and/or SYS: DC-FFS
3. 3.1
4. EyeOfTheBeholder2_v1.1_De_0681

Did some testing under 3.2.1:

8.Ram Disk:> version full 
Kickstart 47.7, Workbench 47.3 (2021-07-13)
8.Ram Disk:> info | search ADH[678] NONUM PATTERN 
ADH6      255M        136     524150   0%   0  Read/Write Temp-FFS
ADH7      236M          2     483782   0%   0  Read/Write Temp-PFS
ADH8      255M        136     524150   0%   0  Read/Write Temp-FFSLN
8.Ram Disk:> version full ram-handler 
ram-handler 47.8 (2021-10-04)
8.Ram Disk:> echo >ram:123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l 
8.Ram Disk:> dir ram:1#? 
  123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j1234567
8.Ram Disk:> version full adh6: 
filesystem 47.4 (2020-06-16)
8.Ram Disk:> echo >adh6:123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l 
8.Ram Disk:> dir adh6:1#? 
  123456789a123456789b123456789c
8.Ram Disk:> version full adh8: 
filesystem 47.4 (2020-06-16)
8.Ram Disk:> echo >adh8:123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l 
8.Ram Disk:> dir adh8:1#? 
  123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456
8.Ram Disk:> version full adh7: 
pfs3aio 19.2 (2018-10-02)
written by Michiel Pelt and copyright (c) 1994-2012 Peltin BV
8.Ram Disk:> echo >adh7:123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l 
8.Ram Disk:> dir adh7:1#? 
  123456789a123456789b123456789c1
8.Ram Disk:> setfnsize adh7: 107 
maximum filename size is now 107
8.Ram Disk:> setfnsize adh7: 108 
The maximum filenamesize is 107
8.Ram Disk:> echo >adh7:123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456789k123456789l 
8.Ram Disk:> dir adh7:1#? 
  123456789a123456789b123456789c1
  123456789a123456789b123456789c123456789d123456789e123456789f123456789g123456789h123456789i123456789j123456

So 3.2.1 testing summary:
- ram: 107,
- FFS 30
- FFS-LN 106
- PFS3AIO 31 as standard, 106 using setfnsize tool set to max 107

Only ram: should be different in 3.1.

A bit strange that both FFS-LN and PFS3AIO maxes out at 106, while ram: reaches the theoretical max of 107 (fib_FileName is 108 but last char is a zero for termination).

[patrik]

Originally Posted by patrik

I think that workbench setting is just a limit for how long filenames workbench itself will show and create, nothing that the filesystems themselves care about.

The problem in 3.1 is the ramdrive handler itself. I even saw a garbled filename in T: when testing under 3.1, so apparently it is not even truncating the file names, but just going bananas. Would be interesting to know what it’s safe limit is.

If you “setenv UHC/TEMPDIR MyPFSDrive:” you can just redirect the tempdir UHC tools uses to a PFS partition.

Just want to correct myself here - I did not see a garbled filename, I only got confused by the list output with the long filename followed by the size .

Also as another note. As EctoOne noticed, lha has no issues with truncated filenames as long as they contain no special characters as it appears it just attempts to open the file as is then and the file system gives the file with the truncated name then.

However, when the filename contains pattern characters like [, even if escaped, it will attempt to match against the actual truncated filename on the disk which it will fail as it is truncated and too short to match the pattern.

[DisasterIncarna]

the plus character seems to be an issue as well as [], only it seems to terminate the filename at the +, but weirdly only for OS3.1, on OS3.2.x the filename does not terminate at the + and carries on to []'s and whatever else ends up goofing up the filename.

this was before your last update, havent tried filenames containing a + since your last update, i assume the escaping you did would probably fix that as well.

[DisasterIncarna]

Originally Posted by spoUP

Double clicking a file in the list to download would be nice.
Viewing collys from asciiarena directly would be nice.

yeah, good ideas, cant believe I totally forgot about a double click.

[patrik]

Originally Posted by DisasterIncarna

the plus character seems to be an issue as well as [], only it seems to terminate the filename at the +, but weirdly only for OS3.1, on OS3.2.x the filename does not terminate at the + and carries on to []'s and whatever else ends up goofing up the filename.

this was before your last update, havent tried filenames containing a + since your last update, i assume the escaping you did would probably fix that as well.

The plus character was fine, the problems are a combination of
1. LhA, the archiver tool
2. truncated filename, so the actual filename is missing the extension (3.1 RAM: handler and FFS max 30)
3. pattern characters in the filename you pass as argument to LhA - one of [ ] ( ) # ? | * % ~ '

Have solved this for the extract script by adding a tool which can check the actual filename of the file on the filesystem. The uhcextract script will compare it against what the filename should be.

If they do not match and the actual filename contains patterns, the file will be renamed a new name keeping 10 chars from the end so the ending will be kept, so LhA will now be able to open it.

Please give it a try.