Are FMUs with symlinks in binaries allowed?

[chrbertsch]

see modelica-tools/FMUComplianceChecker#66

[andreas-junghanns]

I think we need to clarify this issue at least in 3.0, somewhere in "2.5. FMU Distribution", I think.

I just searched through https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT and there symbolic links are only mentioned in "4.5.7 -UNIX Extra Field (0x000d):".
If I read and interpret this correctly, then our platform independence requires that we should not allow it.
Furthermore, this sounds like a feature some zip implementations might not implement or not implement correctly when applied to file systems with varying support of symbol links - anyone with more than my guesswork please report (however subjective).

@pmai : Any wise words to enlighten us mere mortals?

[ven-k]

Adding a rule that The actual file pointed by the included symlinks should also be bundled in the `binaries/linux<32/64> would allow symlinks while ensuring that the FMUs with are relocatable.

To clarify on zip:

• zip in its default zip -rq dest.zip src replaces the symlinks with the actual files.
• In upcoming FMI standards, if the symlinks are allowed and src contains symlinks, zip -rq --symlink dest.zip src would keep the symlinks as it is.
  However, one should note that, if a user doesn't specify --symlink, the .fmu file would still be valid as all required files are bundled; it will only be bigger than it has to be. In other words while this allows those who want ship symlinks, does not affecting those who don't mind about multiple copies of the file.

The changes would be required on the unzipping-end. A sanity check on included symlinks must be run, to ensure they point to a valid file that is bundled in the .fmu's binaries/linux directory.

One might ask- why include additional symlinks when a copy of actual file exists in the binaries. This is to accommodate usage of versioned shared objects where libFoo.so links to libFoo.so.MAJOR links to libFoo.so.MAJOR.MINOR
A practical example is here
The compressed file size compares 250 MB without symlinks to 150 MB with symlinks

[andreas-junghanns]

@pmai : Any comment you want to share here?

[andreas-junghanns]

Web design meeting: We reject support for symlinks in FMUs because:

• The use case is not convincing - why should an FMU have different versions of a library inside that do not exactly use a specific version?
• We believe this is too complicated and will create a lot of importers that will fail to handle symlinks inside the FMUs correctly on their platform/filesystem combination.

We will add a clarification in the standard that symlinks inside FMUs are not allowed - thank you for pointing this out, @ven-k.

[ven-k]

why should an FMU have different versions of a library inside

Versioned shared objects (.so libraries) are used so that whenever there is a newer release libFoo.so.MAJOR.MINOR, you can modify the symlink libFoo.so to link to this newer library and existing code that uses libFoo.so would still work and use the newest version.
It is not for bundling multiple version of the same library inside FMU

Referring to the

A practical example is here

It bundles in libjulia.so which is a symlink to libjulia.so.1.6 and as the newer Julia gets released, a new generated FMU would have libjulia.so.1.7

We believe this is too complicated

Ok

We will add a clarification

Sure. Thanks

[andreas-junghanns]

@ven-k : we know Unix enough to know the mechanisms for "latest" links. However, an FMU must be complete: all needed libraries must be bundled - later changes cannot be made, a new export is needed and then the old library can be removed.