FileCopy of dependencies’s resource is not being processed correctly

[jinlouISC]

OS: MacOS
IPM v0.10.0-beta.15

HS.Timezone and HealthConnect.Common are dependencies of HealthShare.HP.DTR. I am trying to install HealthShare.HP.DTR, then export it into a tarball, and load the tarball in a different namespace.

In HS.Timezone's module.xml, there is the resource using FileCopy:

    <Resource Name="/internal/timezone/" ProcessorClass="%IPM.ResourceProcessor.FileCopy">
      <Attribute Name="Defer">1</Attribute>
      <Attribute Name="InstallDirectory">{$cspdir}/../dev/timezone</Attribute>
      <Attribute Name="Overlay">1</Attribute>
      <Attribute Name="Phase">activate</Attribute>
    </Resource>

In HealthConnect.Common's module.xml, there is the resource using FileCopy:
<Resource Name="/dev/wsdls/" ProcessorClass="FileCopy">

At Package Time

When packaging the module into a tarball locally, the resource /dev/wsdls/ was copied to the root directory of the tarball(/dev/wsdls/), which should ideally be copied to the dependency module's directory (/.modules/healthconnect.common/dev/wsdls/`.

It led to the following error when loading the tarball:

[HealthConnect.Common]	Activate FAILURE
ERROR! Error copying directory /Users/jlou/InterSystems/IRIS/mgr/Temp/dirnOJWCe/.modules/healthconnect.common/dev/wsdls/ to /Users/jlou/InterSystems/IRIS/dev/wsdls/
  > ERROR #5021: Directory '/Users/jlou/InterSystems/IRIS/mgr/Temp/dirnOJWCe/.modules/healthconnect.common/dev/wsdls/' does not exist.

cc'ing @isc-eneil who also reproduced it

Below is part of the original description but is not relevant to this issue anymore.

At Install Time
When installing a module whose dependencies have resources using FileCopy resource processor, IPM throws the following error:

[HS.Timezone]	Activate FAILURE
ERROR! Error creating directory /Users/jlou/InterSystems/IRIS/dev/timezone/: <4294967283> Unknown error: -13

[HealthConnect.Common]	Activate FAILURE
ERROR! Error creating directory /Users/jlou/InterSystems/IRIS/dev/wsdls/: <4294967283> Unknown error: -13

However, when I uninstall the troubled HS.Timezone and HealthConnect.Common modules and reinstall them individually, the error goes away.

[isc-tleavitt]

@jinlouISC the error -13 indicates a permissions issue. Check the user you're running as against the permissions on /Users/jlou/InterSystems/IRIS. It's possible that multithreaded installation could have some impact here and be the difference between installation all at once vs. individually if worker processes are running as a different user.

The real/definite issue here is:
When packaging the module into a tarball locally, the resource /dev/wsdls/ was copied to the root directory of the tarball(/dev/wsdls/), which should ideally be copied to the dependency module's directory

[jinlouISC]

Hi @isc-tleavitt , thank you for your quick response! I am running IRIS terminal as _SYSTEM with %All role, so it should have the permission it needs. So it could be related to multithreading?
But yea I agree that the behavior at package time is more likely an issue here.

[isc-tleavitt]

@jinlouISC I mean you should compare:
What are the OS-level permissions on /Users/jlou/InterSystems/IRIS/dev?
What user are you running IRIS terminal as?

[isc-eneil]

@isc-shuliu @isc-tleavitt @jinlouISC I think there is a second issue here: the <FileCopy> resource processor relies on a source and target. Packaging/publishing introduces an intermediate source and target directory.

The issue is that it is possible to specify a location relative to an IRIS installation directory as an attribute of a <FileCopy> element. For example, ${mgrDir} or ${cspDir}. The file copying occurs during the Activate phase, so if the "publish" command is run at build-time, then any files that are copied relative to an IRIS installation directory will not be present in the packaged tarball.

This works just fine when we are installing modules from source into containers or kits at build-time, but it's problematic for the packaging use case.

Here's a possible solution: if running the package or publish command, skip processing <FileCopy> elements in Activate. Then, the source directory remains the location of a file/directory in the filesystem and the target remains the installation destination on an IRIS instance.

cc @isc-kiyer @isc-jili @isc-jlechtne

[jinlouISC]

@isc-tleavitt OS-level permission for owner jlou is rwx
jlou@usmbp16jlou IRIS % ls -ld /Users/jlou/InterSystems/IRIS/dev drwxr-xr-x 21 jlou irisusr 672 Feb 11 16:59 /Users/jlou/InterSystems/IRIS/dev
im running IRIS terminal as jlou

[isc-tleavitt]

OK - so my theory is:
In multithreaded load, worker processes are running as irisusr (I'm not totally sure on this but I think it's true)
irisusr doesn't have write privilege on the folder -> hits permission error

You should be able to validate this by running the top-level install command with the -DThreads=0 modifier.

[isc-tleavitt]

re: the fix for the actual IPM issue, I think the real need is making sure FileCopy does the right thing in the Export phase-ish-thing used under the hood in packaging.

[jinlouISC]

@isc-tleavitt I installed a new instance and used "irisusr" at this installer prompt: What user should be the owner of this instance? irisusr. For my troubled instance, I have jlou as owner of instance. The permission error -13 is gone and installation completed. So indeed it is a permission issue on my machine!

And yes - I think FileCopy is the real issue in this ticket. I will update the ticket description to reflect that. Thanks!

[isc-shuliu]

OK - so my theory is: In multithreaded load, worker processes are running as irisusr (I'm not totally sure on this but I think it's true) irisusr doesn't have write privilege on the folder -> hits permission error

You should be able to validate this by running the top-level install command with the -DThreads=0 modifier.

I wonder if this is also the cause of #721 (comment)
@isc-tleavitt @jinlouISC @isc-eneil

[isc-eneil]

HSDevOps will pull this issue into our backlog to work on this sprint.
@isc-shuliu @isc-tleavitt
cc @isc-kiyer @isc-jlechtne @isc-jili @jinlouISC