Errors When unpacking Files from External Resource

[J-Camper]

We use an external drafting service in India for some of our overflow work.  We transfer files with them via Pack n Go.  Most of the time this is no issue, but I've gotten some issues with modelstate parts twice on one piece of scope they did for us.  The first time I asked for a new pack n go and those files did not have the errors, so i didn't dig deeper.  This is now the second time I am getting the same errors [although on different part files] so I want to see if anything else can be found out.

I have the bad Pack n go zip folders ready to share with an Autodesk employee, but i will brief the errors I'm getting now.

When I try to open the assembly I get the following error messages:

1. Before the assembly loads I get: "Error loading segment PmGraphicsSegment in Database **...Filename for part issue 1..." [image 1]
2. If I select No when prompted to update assembly, then the application just closes.  If I select Yes the the assembly opens, but i get more error messages when trying to interact.
3. After selecting Yes for assembly to update I get: "Error loading segment PmGraphicsSegment in Database **...Filename for part issue 2..." [image 2]
4. Then I get: "Error in reading RSe stream (4 not equal 0)" [image 3]
5. After that I can move around in the assembly, but if i expand any browser folders with the affected part files i get a repeat of [image 3]

I can open both of the part files individually and they do not give the same errors.  One of them has a bad extrusion on Primary modelstate, but even after fixing that the assembly behaves the same.

Hopefully the new pack n go i requested from the external resource with fix the issue in the short term, but I would like to find out if there is some underlying issue.image 2image 3image 1

[johnsonshiue]

Hi! Are you using Vault to manage the files? Vault may copy the files to %temp% folder. The %temp% path plus the Vault folder path and the file name may exceed 256 characters. Inventor cannot handle such path (regardless of how Windows Long File Path option is set).

Please share the files with me directly (johnson.shiue@autodesk.com).

Many thanks!

[J-Camper]

We do have Vault Basic, but i usually copy the zip file straight to my C drive to unzip due to filename lengths from the transfer folder.  Then i copy the files from that unzipped folder to the proper vault location on my local drive.  The files would not get sent to the vault until i have opened the drawing successfully and check in from Inventor.

I will send the zip folders for this most recent transfer and the previously bad transfer to the email provided.  Also not that we are currently using Inventor Professional 2023 [the latest update: 2023.5.2], but the first time we got the transfer issue we were on 2023.5.

[johnsonshiue]

Hi! Jeff did share the files with me. Without disclosing the detail, I can comment as such. The corruption is confirmed. It is specific to some parts with Model States. Inventor has trouble reading the member documents embedded in the Model States parts. The cause leading to the corruption is unknown at the moment. Unfortunately, the parts will need to be redone or the Model States need to be recreated.

Many thanks!

[J-Camper]

Thank you Johnson for looking into this.  I did initially try to fix the parts myself, but while I could get the parts to appear fixed in the part file, I was never able to get the assembly referencing them fixed. 

Luckily the issue was only present in the files I unpacked, so I was able to avoid the issue by requesting a new pack n go.  The new files I received a day later were not corrupt when I unpacked them, so we were able to move on.

I made this post as it was the second time this particular package experienced the corruption upon unpacking.  I asked the partners in India if they did anything different between the two recent pack n go's but apparently they did the same procedure both times.

I'm not sure if the corruption occurred during pack n go, or unpacking but it has been extremely rare in my experience.