Click Here
home features news forums classifieds faqs links search
6005 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
62 crawler(s) on-line.
 13 guest(s) on-line.
 1 member(s) on-line.


 Steady

You are an anonymous user.
Register Now!
 Steady:  29 secs ago
 DiscreetFX:  51 mins ago
 freak:  56 mins ago
 agami:  1 hr 11 mins ago
 matthey:  1 hr 58 mins ago
 Hypex:  2 hrs 6 mins ago
 RobertB:  2 hrs 37 mins ago
 simplex:  2 hrs 59 mins ago
 JKD:  2 hrs 59 mins ago
 ne_one:  3 hrs 3 mins ago

/  Forum Index
   /  Amiga OS4.x \ Workbench 4.x
      /  New mini update from Hyperion part #2
Register To Post

Goto page ( Previous Page 1 | 2 )
PosterThread
nbache 
Re: New mini update from Hyperion part #2
Posted on 20-May-2021 23:24:10
#21 ]
Super Member
Joined: 8-Apr-2003
Posts: 1009
From: Copenhagen, Denmark

@Gregor

Quote:
In my system (AmigaOS 4.1FEu2, X5000) AmiUpdate does not see at all that Installer update... I have in the 'servers' menu 'www.amiupdate.net' and 'update.amigaos.net', and both are selected.
Maybe try (temporarily) deselecting www.amiupdate.net, as it looks like the below error message stems from there, so maybe it confuses the program when trying the next server.

Quote:
16:54:07 This update has a listed requirement with an invalid syntax (Amiga PPC and AmigaOS4 final edition Update 2), checking aborted
(I'm guessing this must be a DB config error for some other, third-party update on the AmiUpdate.net server.)

If it doesn't help to only use the AmigaOS server, it could be a temporary connection error - although it doesn't much look like it from the log.

What do you get when entering "version Installer FILE FULL" in a Shell? If it says 53.11, you already have it installed somehow. Note that no reboot is required for this update, so maybe you didn't notice it being installed earlier?

Best regards,

Niels


 Status: Offline
Profile     Report this post  
matthey 
Re: New mini update from Hyperion part #2
Posted on 21-May-2021 4:17:43
#22 ]
Cult Member
Joined: 14-Mar-2007
Posts: 971
From: Kansas

Chris_Y Quote:

I can see an issue if you save to a softlinked directory in RAM:, expecting it to write to the original location... however it only writes it to RAM:. This could cause confusion (and loss of data)

OK, so the chances of somebody creating a directory softlink in RAM: and then using it to read/write files is slim, but it's still unexpected behaviour.


With the soft link copy on demand cache method, I would expect writes to ENV: memory would need to go back to the soft linked file in ENVARC: or it isn't really a soft link. I don't see how this could be the case as prefs "use" writes ENV:xxx.prefs and should *not* write ENVARC:xxx.prefs. A prefs "save" writes ENVARC:xxx.prefs which avoids the soft link but also writes ENV:xxx.prefs which should be redirected to ENVARC:xxx.prefs.

MakeLink RAM:ENV to ENVARC: FORCE

xxx Prefs startup: read from ENV:xxx.prefs
1. if !exists(ENV:xxx.prefs) copy(ENVARC:xxx.prefs to ENV:xxx.prefs)
2. read(ENV:xxx.prefs)
The expected behavior of a soft link is to read ENVARC:xxx.prefs which this does in a slow and round about way.

xxx Prefs use: write to ENV:xxx.prefs
1. write(ENV:xxx.prefs)
The expected behavior of a soft link is to write ENVARC:xxx.prefs!

xxx Prefs save: write to ENVARC:xxx.prefs and ENV:xxx.prefs
1. write(ENVARC:xxx.prefs)
2. write(ENV:xxx.prefs)
The soft link is avoided as expected in the first write but there would be no way to write ENV:xxx.prefs with a soft link in place as the write would be redirected to ENVARC:xxx.prefs.

The alternate method of a soft link which I described to eliminate the need for an env-handler is simpler and saves more memory but also suffers from unexpected soft link behavior.

xxx Prefs startup: read from ENV:xxx.prefs
1. if exists(ENV:xxx.prefs) read(ENV:xxx.prefs) else read(ENVARC:xxx.prefs)
The expected behavior of a soft link is to read ENVARC:xxx.prefs which this does unless there is a local cached copy available.

xxx Prefs use: write to ENV:xxx.prefs
1. write(ENV:xxx.prefs)
The expected behavior of a soft link is to write ENVARC:xxx.prefs!

xxx Prefs save: write to ENVARC:xxx.prefs and ENV:xxx.prefs
1. write(ENVARC:xxx.prefs)
2. write(ENV:xxx.prefs)
The soft link is avoided as expected in the first write but there would be no way to write ENV:xxx.prefs with a soft link in place as the write would be redirected to ENVARC:xxx.prefs.

Rather than making either of these soft link methods the default behavior, perhaps a preferable option would be to have a new MakeLink CACHE option. I call it a "cache" because that is how I would describe this behavior. It allows to edit a cache of files without overwriting the original files. Perhaps this behavior would be useful for other applications as well?

Speaking of unexpected or inconsistent behavior, lets look at the AmigaOS 4.x MakeLink command.

https://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Command_Reference#MAKELINK

AmigaOS wiki Quote:

By default, or when the SOFT keyword is given, MAKELINK tries to create a soft link. When the HARD keyword is given, MAKELINK tries to create a hard link. (Note that the default changed to this from version 53.3+)


Is it possible for MAKELINK to internally detect whether the link will be HARD or SOFT and create the appropriate link (perhaps failing if an optional HARD or SOFT specifier is incorrect)?

AmigaOS wiki Quote:

Also by default when doing soft links, if the destination path is relative (i.e. a path not prefixed by a volume name), MAKELINK will try to resolve it relative to the directory which will contain the link, it will not resolve it relative to the current directory like other commands. See examples below.

...

SYS:> MakeLink RAM:Link S/User-Startup SOFT

will create a soft link to RAM:S/User-Startup (this file must exist) and not to SYS:S/User-Startup as one could expect.


The Amiga could have one of the best hard and soft link implementations of any OS and could have consistency between AmigaOS 68k and AmigaOS PPC allowing easier support of both but this doesn't give me much confidence.

Last edited by matthey on 22-May-2021 at 08:07 AM.
Last edited by matthey on 22-May-2021 at 01:58 AM.
Last edited by matthey on 21-May-2021 at 04:44 AM.
Last edited by matthey on 21-May-2021 at 04:37 AM.

 Status: Offline
Profile     Report this post  
Gregor 
Re: New mini update from Hyperion part #2
Posted on 21-May-2021 6:32:18
#23 ]
Regular Member
Joined: 12-Sep-2011
Posts: 199
From: Unknown

@nbache
Quote:
Maybe try (temporarily) deselecting www.amiupdate.net, as it looks like the below error message stems from there, so maybe it confuses the program when trying the next server.

Deselecting www.amiupdate.net did not help... Nothing was found.

Quote:
What do you get when entering "version Installer FILE FULL" in a Shell? If it says 53.11, you already have it installed somehow. Note that no reboot is required for this update, so maybe you didn't notice it being installed earlier?

'Version' cannot found the Installer. Obviously I do not have an earlier version. Where should it normally be located?

 Status: Offline
Profile     Report this post  
nbache 
Re: New mini update from Hyperion part #2
Posted on 21-May-2021 23:18:14
#24 ]
Super Member
Joined: 8-Apr-2003
Posts: 1009
From: Copenhagen, Denmark

@Gregor

Quote:
'Version' cannot found the Installer. Obviously I do not have an earlier version.
That is very strange, it has been in the OS by default for ages.

Maybe you don't have SYS:Utilities in your path for some reason. Try with "version SYS:Utilities/Installer FILE FULL".

Quote:
Where should it normally be located?
Its normal place is SYS:Utilities/Installer. But note that it does not have an icon, so if you're looking for it from WB, remember to switch on "Show all files".

Best regards,

Niels

 Status: Offline
Profile     Report this post  
cdimauro 
Re: New mini update from Hyperion part #2
Posted on 22-May-2021 10:14:57
#25 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2252
From: Germany

@kas1e Quote:

kas1e wrote:

There is no more profit for him on the OS4 front, so we can be 99% sure that he will spend shit on paying developers. But from another side, strange why he just didn't sell out AOS4 components, he owns completely to someone who in interest still. Year, or two, and no one will give him for OS4 ownership a shit.

This isn't only a problem for OS4 rather for all (closed source) Amiga/-like o.ses.

It doesn't make sense at all to develop parallel copies of the same stuff, reinventing the wheel each time.

What value has for all o.ses to jealously keep for themselves things like the DOS commands? The USB stack? And so on. Those are NOT killer features which can attract users!

A smarter move would have been make public, under the same repository, all this stuff.

The rest, like the exec, graphics, even MUI, etc. which has some "value" AKA "killer feature" can still remain closed.
Quote:
And probably no one will be in will to buy anything as well from him, he will cheat everyone, so later to take the rights back :)

Well, people is happily filling his pockets buying AmigaOS 3.2...

 Status: Offline
Profile     Report this post  
kolla 
Re: New mini update from Hyperion part #2
Posted on 23-May-2021 3:35:12
#26 ]
Super Member
Joined: 21-Aug-2003
Posts: 1671
From: Trondheim, Norway

What am I using softlinks in RAM: for? Well, T: is in RAM: and I have an ondisk softlink from SYS:WBStartup that points to T:WBStartup, which is also a softlink pointing to the directory currently used as WBStartup. This T:WBStartup softlink is created on boot and will point to different directory depending on various criteria, which "desktop environment" the system is booting into etc. This works great and rather transparent, without any need to make changes to disk during boot. When files are written to SYS:WBStartup, softlinks are followed and files are written to the dicretory which T:WBStartup points at. As expected. I suspect this will break with ram-handler v47, as writing to T:WBStartup will then somehow fill up RAM: instead, and not be preserved in the directory that T:WBStartup points to.

Unless "new magical softlink method" only affects RAM:ENV.

Last edited by kolla on 23-May-2021 at 03:35 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
kolla 
Re: New mini update from Hyperion part #2
Posted on 23-May-2021 3:41:25
#27 ]
Super Member
Joined: 21-Aug-2003
Posts: 1671
From: Trondheim, Norway

@matthey

Just to say something obvious which seems less obvious when reading your postings.... - HARD links only works within the same filesystem, cross filesystem links have to be SOFT.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

 Status: Offline
Profile     Report this post  
cdimauro 
Re: New mini update from Hyperion part #2
Posted on 23-May-2021 8:32:56
#28 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2252
From: Germany

@kolla Quote:

kolla wrote:
@matthey

Just to say something obvious which seems less obvious when reading your postings.... - HARD links only works within the same filesystem, cross filesystem links have to be SOFT.

Correct. However it might be that being on the same filesystem isn't enough for hard links, and that they should stay on the same device.

 Status: Offline
Profile     Report this post  
matthey 
Re: New mini update from Hyperion part #2
Posted on 23-May-2021 17:57:29
#29 ]
Cult Member
Joined: 14-Mar-2007
Posts: 971
From: Kansas

kolla Quote:

What am I using softlinks in RAM: for? Well, T: is in RAM: and I have an ondisk softlink from SYS:WBStartup that points to T:WBStartup, which is also a softlink pointing to the directory currently used as WBStartup. This T:WBStartup softlink is created on boot and will point to different directory depending on various criteria, which "desktop environment" the system is booting into etc. This works great and rather transparent, without any need to make changes to disk during boot. When files are written to SYS:WBStartup, softlinks are followed and files are written to the dicretory which T:WBStartup points at. As expected. I suspect this will break with ram-handler v47, as writing to T:WBStartup will then somehow fill up RAM: instead, and not be preserved in the directory that T:WBStartup points to.


You are using MakeLink for directories which is what I was trying to ask. It does look like you could be affected by changed behaviors of MakeLink. I do find it odd that you would use a link to a link and have a need for WBStartup to be in memory as these programs are executed only once. Maybe the equivalent of the drag and drop startup pref from AmigaOS 4 that eliminates moving programs to the WBstartup directory would be useful to you but that is another topic.

kolla Quote:

Unless "new magical softlink method" only affects RAM:ENV.


I hope not. In my opinion, that would be a bad design for different devices to have different behavior. It would be better to add a new MakeLink CACHE option which allows all expected behavior of links to be retained when the option is missing.

kolla Quote:

Just to say something obvious which seems less obvious when reading your postings.... - HARD links only works within the same filesystem, cross filesystem links have to be SOFT.


I know the difference between a hard and soft link. I was confused by the FORCE option of MakeLink which I thought was needed for a SOFT link (I initially looked at old MakeLink which does not have a SOFT option). I don't think this is true now but I'm still not sure whether FORCE is needed when the paths are directories instead of files or when one of the paths doesn't exist yet. The documentation is a mess too because of differences between AmigaOS 3 and 4, inconsistent and unexpected behaviors, varied device support and bugs.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle