FMUs with curly brackets in guid are failing

[ljamt]

Earlier we simply removed { and } from the FMU GUIDs, with PR 388 we now percent encode them. The problem occurs when the FMU tries to reach files in /resources and itself (or FMI library) also do percent encoding. Leading to the following:

Failed to open file .../Temp/cse_e7409bf5-94da-4771-8cac-26ff9a2c0d8e/%257B7041d910-6424-4284-89c5-5246b4b483c3%257D/resources/ MotorGenPackV3_MotorGenerator_CV_FMU3_info.json for reading: No such file or directory

Here the percent itself is encoded as the real path is
.../%7B7041d910-6424-4284-89c5-5246b4b483c3%7D/...

Not encoding the curly brackets is not a solution as the fmu tries to reach a path containing .../%7B7041d910-6424-4284-89c5-5246b4b483c3%7D/... which is not the same as .../{7041d910-6424-4284-89c5-5246b4b483c3}/...

I suggest that we go back to removing the curly brackets from the GUID when creating the directory.

Maybe an option could be to provide fmuResourceLocation instead of nullptr when we call fmi2_import_instantiate in fmu.cpp. FMI library sets a default for us (as already mentioned by @markaren here). Tested with providing the fmuResourceLocation, and reports failure on mismatching path due to percent encoding.

[ljamt]

BTW, this is a blocker for the use cases.

[kyllingstad]

I would say that this is a bug in the FMU. The FMI standard clearly says that fmuResourceLocation must be interpreted as an RFC3986-compliant URI, which, among other things, includes percent encoding.

That said, I'm all for fixing this in the way you suggest, but mainly because I think the Microsoft-style GUID formatting {...} should be banished from the world of software forever and replaced everywhere with proper RFC4122-style formatting without the brackets. 😉