FhSim  3.1.0
Marine systems simulation
Loading...
Searching...
No Matches
0026 — --autocopy warns of a bundle-name clash whenever one file is referenced twice
ID 0026
Class BUG
Severity 1
Status ready
Models — (FhFmuExport --autocopy)
Found 2026-09-25, verifying fhsim_fishery FISH-0044 (AuvSurvey FMU export against 83b4470a)
Decision needed —

Evidence

warnOnBundleNameClash (src/fmu/fhFMUexport/FmuResourceCopier.cpp:95-102) is meant to warn "when two different sources want the same name under `auto_copied/`". Its test is

if (fs::exists(destination, lookup) && !fs::equivalent(source, destination, lookup) && !lookup) {

where source is the resolved attribute value and destination is the bundled copy auto_copied/<leaf> (called from bundleReference, :143). A bundled copy is a separate file from the playpen file it was copied from, so fs::equivalent(source, destination) is always false once the copy exists. The test therefore fires for every reference after the first to the same file, not only for two different files that share a leaf name.

Observed: fhsim_fishery's AuvSurvey model names one field file from five attributes (ScalarField.<Name>.ConfigFile = "../examples/input/fishery/auv_ocean_fields.json"). Exporting it with --autocopy, from either the visual or the headless playpen, prints four times

WARNING: --autocopy overwrites <fmu>/resources/auto_copied/auv_ocean_fields.json with
<playpen>/bin/../examples/input/fishery/auv_ocean_fields.json; two references share one bundled name.

although all five references name one file and the bundle is correct.

Effect

The warning that exists to flag a real clash (two different data.csv files, one silently lost) is printed for the ordinary case of a shared input file, so a user learns to ignore it. The export result itself is correct.

Possible fix

Remember which source produced each bundled name during CollectFileReferences (a map from leaf to the canonical source path) and warn only when a later source's canonical path differs from the recorded one. Comparing file content instead would also silence identical copies of different files, which is arguably still worth a warning.

Test that would prove it

Extend the fmu-autocopy fixture (tests/cmake/fmu_export.cmake:385 onward, tests/in/FMDirectionalDerivative/AutoCopy_in.xml) with a second attribute naming AutoCopyData.json, and assert that the export's stderr has no overwrites line; add a case with two different files of one leaf name and assert that it does.

Risk

Diagnostic output only.