Files generated with version 3.2.0 fail to load in various applications

[dgirardeau]

Hi,

Some CloudCompare users have reported that the files saved with version 3.2.0 of libE57Format won't open with Rhino8, SolidWorks 2023 and FARO Scene. Reverting to version 3.1.1 seems to fix the issue.

It seems to be related to this commit: feaa963 (I've generated files with version 3.2.0 with only this commit reverted, and it seems to work fine). Even though it seems to be 'required by the standard', I guess these SW solutions are not able to handle the single CV index packet properly?

Maybe a solution would be to add a boolean somewhere to control whether this CV index packet should be automatically added or not? (with a default state to true)

@dancergraham I've attached a file that fails to load with the above applications. pumpsA_3.2.0.e57.zip

[dancergraham]

the rust e57 library seems to skip over index packets - I can read this file successfully with my e57 python library https://github.com/cry-inc/e57/blob/bdb8fa9015b1e87d5c600860c51002e25cb95c7d/src/queue_reader.rs#L80

[nigels-com]

Problems here too for v3.2.0 E57 to Cintoo cloud service.
Reverting the mentioned commit works for us too.
https://cintoo.com/

[asmaloney]

This should be reported to the applications that are failing. They will fail on any E57 file containing index packets.

My guess is they are based on either the original reference implementation or an older version of this library - both of which fail to read index packets properly (they throw an exception).

I fixed it in libE57Format somewhere along the way, so if they are using this they just need to update.

[nigels-com]

It's not realistic for us to require all our customers to chase their vendors to update their E57 reader.
We're going to want a compile-time opt-out for this for a good while, I expect.
(Better that than rolling back to v3.1.1, right?)

I am happy to raise it with Cintoo, but I'm not sure our relationship with them is going to be a particularly high priority.

[VxGrid]

This seems to be a chicken - egg problem, since the reader as well as the writer are affected.

On the one hand I'd prefer the new reader, which fixes the non standard stuff, on the other I'd like to keep the old writer due to compatibility issues. Especially concerning other applications which won't update.
A compile time flag would be good, a runtime flag even better, perhaps a boolean in WriterOptions?

[az-faro]

Just wanted to add that we have the same issue. And I do agree with @asmaloney that this IS a client side error due to not following the standard, but in the real world unfortunately we have to try to be flexible. Having a switch to disable it would be awesome so we can remain on the latest version from a security and functionality perspective.

[az-faro]

I added a PR to add such a flag: #321