[sword-devel] SWORD module installation bug

[ZdPo Ster]

installmgr on windows (git svn revision 3887) does not seem to have this
problem:

>dir %SWORD_PATH%\modules\lexdict\zld\slkstrongsgreek
 Volume in drive F is Elements
 Volume Serial Number is A056-4331

 Directory of F:\win64\share\sword\modules\lexdict\zld\slkstrongsgreek

13.11.2022  14:49    <DIR>          .
13.11.2022  14:49    <DIR>          ..
13.11.2022  14:49            95 608 dict.dat
13.11.2022  14:49            44 992 dict.idx
13.11.2022  14:49           778 434 dict.zdt
13.11.2022  14:49             1 504 dict.zdx

>installmgr -li SlkStrongsGreek SlkStrongsGreek

Installed module: [SlkStrongsGreek]

>dir %SWORD_PATH%\modules\lexdict\zld\slkstrongsgreek
 Volume in drive F is Elements
 Volume Serial Number is A056-4331

 Directory of F:\win64\share\sword\modules\lexdict\zld\slkstrongsgreek

13.11.2022  14:49    <DIR>          .
13.11.2022  14:49    <DIR>          ..
13.11.2022  19:38            95 608 dict.dat
13.11.2022  19:38            44 992 dict.idx
13.11.2022  19:38           778 553 dict.zdt
13.11.2022  19:38             1 504 dict.zdx


On Sun, 13 Nov 2022 at 09:55, Tobias Klein <contact at tklein.info> wrote:

> I could just reproduce this issue.
>
> I have a test user with an older set of SWORD modules and by keeping a
> backup of the .sword directory I could switch back to the state before
> the module update.
>
> Once I applied the module update again ... I had the same issue as
> described below.
>
> The way how I have implemented the module update is by simply running
> installModule on top of an existing installation. Is that an invalid
> approach?
>
> What I will now do next is add an explicit InstallMgr::removeModule()
> call before re-installing the new version.
>
> If that's what's needed - maybe there should be an upgradeModule()
> method? Or alternatively the installModule() should return with an error
> code when the given module is already installed?
>
> This may also explain how I ran into this before ... I have an e2e
> integration test suite of Ezra Bible App. And that test suite
> automatically runs through the module installation process as one of the
> test scenarios. It doesn't cleanup the .sword directory initially,
> though. Which means that it installs modules on top of existing modules
> ... and that's where I may have seen this issue before as well!
>
> Best regards,
> Tobias
>
> On 11/12/22 10:56 AM, Tobias Klein wrote:
> > Hi all,
> >
> > I have observed a bug with regard to SWORD module installation.
> >
> > I just tried to update existing modules by "installing them again"
> > using InstallMgr::installModule().
> >
> > I ended up with a situation where the installation apparently finished
> > ok based on return codes, but then I found the following:
> >
> > The *.conf files in the mods.d directory are still present, but the
> > module contents under modules/texts/ztext are actually removed for the
> > modules that I tried to update.
> >
> > Has anyone seen this behavior before? Is there an explanation?
> >
> > The modules are then still listed as installed, but there is no
> > content ...
> >
> > I have seen this before at various times with individual modules, but
> > did not report it. Now that I have this bug at a larger scale (for a
> > bigger list of modules I tried to update) I felt like it's worth
> > reporting.
> >
> > Best regards,
> > Tobias
> >
> > PS: I have been using SWORD SVN Rev. 3873 (from Nov. 2021).
> >
> > _______________________________________________
> > sword-devel mailing list: sword-devel at crosswire.org
> > http://crosswire.org/mailman/listinfo/sword-devel
> > Instructions to unsubscribe/change your settings at above page
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20221113/02e7c051/attachment.htm>