Update installer to allow installation even while AmiSSL is in use about amissl

[ksdhans]

I just discovered that something puts a lock on the library(s) while it's in use. Perhaps AmiSSL itself is doing this? I can rename/overwrite other libraries even though they're in use, so the OS itself doesn't lock libraries that are currently open.

[Futaura]

Yes, you're right - it is most likely due to:

amissl/src/amissl_libinit.c

Line 718 in dd7c209

if(base->elfHandle && (base->elfHandle = (base->IElf->OpenElfTags)(OET_ElfHandle, base->elfHandle, TAG_DONE)))

which cannot easily be avoided AFAIK, due to the baserel stuff / IElf->CopyDataSegment(), which needs the Elf handle. IBrowse has the same issue, for the same reason.

The AmiSSL installer itself employs some tricks (renaming the libraries) to flush the libraries from memory, otherwise the installer would also fail even if the libraries were resident in memory, but not in use. Of course, this only works if nothing has AmiSSL open. I hope updating AmiSSL via AmiUpdate is not affected by this, as I did advise that AmiUpdate needs to close AmiSSL before trying to update AmiSSL.

[ksdhans]

It's not just AmiUpdate. ZitaFTPServer has the problem too. I will be updating the installer to shutdown the server first. However, if the user still has their web-browser open then it'll still fail.

[Futaura]

Of course, any application that has AmiSSL open will prevent the installer from working. I just mentioned AmiUpdate as a special case.

Anyway, this problem has always bothered me and it is indeed OpenElf() that puts a lock on the libraries. CopyDataSegment() unfortunately needs to read relocation information from the file each time it is called (everytime the library is opened). This lock has to be maintained while the library is in memory, otherwise if you update AmiSSL and overwrite the libs, while AmiSSL is in use, if some application then opens AmiSSL it will probably crash due to CopyDataSegment() reading from the newer file.

I've been looking at the elf.library source code and there just doesn't seem to be a good way around it, in terms of the AmiSSL libinit code. Perhaps the only solution is to make the installer rename the libraries to amissl*.library-old (for example) and at least the libraries can then be installed - the new version just won't be used until after a reboot or if the old version is expunged.

[Futaura]

@ksdhans I figured out a way to preload the required data relocs, allowing the file lock to be released during initialisation (instead of expunge), which means that once users have AmiSSL 5.4 installed, future updates will be able to install even if AmiSSL is currently running or in memory (just as would normally happen on OS3).

[ksdhans]

Nice! The ZitaFTP Server installer can now shut it down, but it won't help with the AmiSSL update if something else is using it...

Looking forward to AmiSSL 5.4...

[Futaura]

Final fix for this is in AmiSSL 5.13

[Futaura]

And now that elf.library 54.1 has been released to the public, it is now time to finally close this issue.