English Amiga Board


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 27 September 2022, 19:45   #121
Swe_Kryten2x4b
Registered User

 
Join Date: Sep 2017
Location: Uppsala
Posts: 105
Quote:
Originally Posted by DisasterIncarna View Post
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.
Attached Thumbnails
Click image for larger version

Name:	uhc.png
Views:	26
Size:	42.6 KB
ID:	76685  
Swe_Kryten2x4b is offline  
Old 27 September 2022, 21:02   #122
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
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.
EctoOne is offline  
Old 28 September 2022, 01:13   #123
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
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.
DisasterIncarna is offline  
Old 28 September 2022, 08:49   #124
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
My mistake. I didn't replace the old Exe, I replaced my launch script. It's still working fine.
EctoOne is offline  
Old 28 September 2022, 08:54   #125
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
DisasterIncarna is offline  
Old 29 September 2022, 00:52   #126
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
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
Attached Files
File Type: zip UHC-Disk.zip (880.0 KB, 13 views)
EctoOne is offline  
Old 29 September 2022, 01:36   #127
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
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?
DisasterIncarna is offline  
Old 29 September 2022, 01:58   #128
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
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.
EctoOne is offline  
Old 29 September 2022, 22:48   #129
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
Quote:
Originally Posted by DisasterIncarna View Post
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.
patrik is offline  
Old 29 September 2022, 23:34   #130
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
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?
DisasterIncarna is offline  
Old 30 September 2022, 00:11   #131
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
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.
patrik is offline  
Old 30 September 2022, 13:23   #132
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
I just noticed the long filename issue also for whdownload. Something like EyeOfTheBeholder2_v1.1_De_0681.lha gets cut off.
EctoOne is offline  
Old 30 September 2022, 20:15   #133
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
Quote:
Originally Posted by EctoOne View Post
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?
patrik is offline  
Old 30 September 2022, 21:57   #134
EctoOne
Registered User
EctoOne's Avatar
 
Join Date: Jun 2020
Location: Germany
Posts: 149
Quote:
Originally Posted by patrik View Post
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
EctoOne is offline  
Old 30 September 2022, 23:05   #135
spoUP
Registered User
 
Join Date: Dec 2002
Location: sweden
Age: 44
Posts: 393
Double clicking a file in the list to download would be nice.
Viewing collys from asciiarena directly would be nice.
spoUP is offline  
Old 01 October 2022, 03:15   #136
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
Quote:
Originally Posted by EctoOne View Post
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:
Code:
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 is offline  
Old 01 October 2022, 03:50   #137
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
Quote:
Originally Posted by patrik View Post
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.
patrik is offline  
Old 01 October 2022, 05:20   #138
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
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 is offline  
Old 01 October 2022, 05:22   #139
DisasterIncarna
Registered User

DisasterIncarna's Avatar
 
Join Date: Oct 2021
Location: England
Posts: 629
Quote:
Originally Posted by spoUP View Post
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.
DisasterIncarna is offline  
Old 04 October 2022, 01:04   #140
patrik
Registered User
patrik's Avatar
 
Join Date: Jan 2005
Location: Umeå
Age: 42
Posts: 740
Quote:
Originally Posted by DisasterIncarna View Post
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.
patrik is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
UHC Tools jayminer Amiga scene 179 25 November 2022 01:35
[WIP] Scramble jotd project.Amiga Game Factory 141 20 April 2022 20:57
WIP: Stormlord Ultron project.Sprites 5 25 January 2016 21:13
M.O.V.I.E. Spriteset - WIP invent project.Sprites 2 11 July 2014 05:58
Kumiko GUI - Amiga Workbench 3.1 GUI for Windows milika Amiga scene 31 18 April 2007 20:16

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.11428 seconds with 14 queries