Uninstall a module with a FileCopy resource shouldn't delete the entire directory

[isc-jlou]

Describe the bug

If a module copy files into a shared directory and you uninstall that module, the shared directory would be deleted. As an example, HealthConnect.FHIRMeta and HealthConnect.FHIRMeta.R5 both copy files into /dev/fhir/fhir-metadata/. I have a solution module that only needs HealthConnect.FHIRMeta. When I uninstall my solution module, the entire /dev/fhir/fhir-metadata/ directory is deleted.

To Reproduce

Steps to reproduce the behavior:

1. Run IPM command 'install HealthConnect.FHIRMeta'
2. Verify the following 3 packages are copied into instance directory /dev/fhir/fhir-metadata/packages: hl7.fhir.r3.core, hl7.fhir.r4.core, hl7.fhir.us.core
3. Run IPM command 'install HealthConnect.FHIRMeta.R5'
4. Verify the following 1 package is copied into instance directory /dev/fhir/fhir-metadata/packages: hl7.fhir.r5.core
5. Run IPM command 'uninstall HealthConnect.FHIRMeta'
6. Verify the issue: the entire /dev/fhir/fhir-metadata/ directory is deleted.

Expected Behavior

A FileCopy resource has Overlay=1 should keep track of its files and only delete those on uninstall instead of the entire directory. In this example, /dev/fhir/fhir-metadata/ should exist with 1 package: hl7.fhir.r5.core. Also, if an overlay=1 FileCopy sees an identically named existing file, show a warning, but don't fail.

System information (please complete the following information):

• IPM version: 0.10.4
• IRIS version: IRIS for UNIX (Apple macOS for Apple Silicon) 2025.1.2 (Build 349U)
• OS: Apple macOS for Apple Silicon
• Docker or local: local

[isc-clangell]

I'm not sure that the "Expected Behavior" will be enough to fully fix the problem. In this example, the files under /dev/fhir/fhir-metadata/packages/ are all installed by I4H and might be used by multiple packages. Just making sure that the file doesn't delete the whole directory isn't enough since uninstalling once instance of this shouldn't remove these files if they were installed by something else. This may be a larger problem with the FHIR meta packages using the same directories as I4H, but it may also be worth adding a tag to FileCopy in module xml definition to specify that some file should never be deleted.