Poster | Thread |
nbache
| |
Re: New mini update from Hyperion part #2 Posted on 20-May-2021 22:24:10
| | [ #21 ] |
|
|
|
Super Member |
Joined: 8-Apr-2003 Posts: 1034
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 |
|
|
matthey
| |
Re: New mini update from Hyperion part #2 Posted on 21-May-2021 3:17:43
| | [ #22 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1968
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 07:07 AM. Last edited by matthey on 22-May-2021 at 12:58 AM. Last edited by matthey on 21-May-2021 at 03:44 AM. Last edited by matthey on 21-May-2021 at 03:37 AM.
|
|
Status: Offline |
|
|
Gregor
| |
Re: New mini update from Hyperion part #2 Posted on 21-May-2021 5:32:18
| | [ #23 ] |
|
|
|
Regular Member |
Joined: 12-Sep-2011 Posts: 212
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 |
|
|
nbache
| |
Re: New mini update from Hyperion part #2 Posted on 21-May-2021 22:18:14
| | [ #24 ] |
|
|
|
Super Member |
Joined: 8-Apr-2003 Posts: 1034
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 |
|
|
cdimauro
| |
Re: New mini update from Hyperion part #2 Posted on 22-May-2021 9:14:57
| | [ #25 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3621
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 |
|
|
kolla
| |
Re: New mini update from Hyperion part #2 Posted on 23-May-2021 2:35:12
| | [ #26 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 2859
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 02:35 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
kolla
| |
Re: New mini update from Hyperion part #2 Posted on 23-May-2021 2:41:25
| | [ #27 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 2859
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 |
|
|
cdimauro
| |
Re: New mini update from Hyperion part #2 Posted on 23-May-2021 7:32:56
| | [ #28 ] |
|
|
|
Elite Member |
Joined: 29-Oct-2012 Posts: 3621
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 |
|
|
matthey
| |
Re: New mini update from Hyperion part #2 Posted on 23-May-2021 16:57:29
| | [ #29 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1968
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 |
|
|