Pack and Go 2023 Duplicate filenames in red?

[JMOS4]

Hi all,

Getting a error with 2023 pack and go it gives this dialog but nothing is red so what gives

Regards,
Jim

[AlexLachance]

2023 is only in BETA, your question should be adressed to them directly.

Edit: Have you actually looked any further than for red? The message is pretty specific, look into that, maybe that could give you a clue.

[JMOS4]

Hi Again,

I looked although it did have some virtual parts so maybe that has something todo with the error, never seen it before but at a new job so who knows how things are configured so to speak.

Regards,
Jim

[AlexLachance]

Hi Again,

I looked although it did have some virtual parts so maybe that has something todo with the error, never seen it before but at a new job so who knows how things are configured so to speak.

Regards,
Jim

I'd say virtual parts would be a pretty good guess. Have you tried doing the same pack and go but with only one file selected?

[josh]

Pack and Go is bugged - 2022 is the same.

If you have an assembly that references more than one file with the same name (for example, Screw.sldprt that's stored in multiple different locations), PnG will never allow you to proceed. Even if these files are de-selected for copying. Even if these same-name files are suppressed, it will keep putting the filenames in red. Even if you change the filenames.

[tsmith]

Can confirm, having the same problem SOMETIMES with 2022.2.

[jcapriotti]

Pack and Go is bugged - 2022 is the same.

If you have an assembly that references more than one file with the same name (for example, Screw.sldprt that's stored in multiple different locations), PnG will never allow you to proceed. Even if these files are de-selected for copying. Even if these same-name files are suppressed, it will keep putting the filenames in red. Even if you change the filenames.

Because this should never be done, ever. I would be glad PnG is preventing it from even trying to copy the structure until this issue is fixed in the files. Did I mention this should never be done, ever?

[josh]

Because this should never be done, ever. I would be glad PnG is preventing it from even trying to copy the structure until this issue is fixed in the files. Did I mention this should never be done, ever?

Of course it shouldn't be done, but I didn't want it to copy the files. I didn't even want it to copy the structure. The offending files were suppressed components of suppressed assemblies, and I selected the option not to include suppressed components. My purpose for the PNG was to send it to someone who would never have a chance to possibly encounter the duplicate filenames. Even if the structure were copied, it would never cause a problem because these other "same name" files are actually copies of the exact same file, just in a different directory. So the models even open up just fine. These are large complex assemblies all with multiple configs each with different suppression states which I didn't have the time to dig through and fix. I absolutely knew what the F I was doing. If SW was willing to save the files in the first place, it should be fine with a PNG.

[jcapriotti]

@josh I guess call me "jaded" to the whole "duplicate" issue, but I've been fighting this with users for 20+ years. If I had my way, SolidWorks would completely block users from ever doing anything with duplicate filenames until its fixed. I've spent many hours troubleshooting user issues only to find out that there was a duplicate copy of a file somewhere. It's frustrating when a user says "My changes are gone, this software sucks"....then you find out they had a copy somewhere with their changes but they loaded the original version and they get errors. They should've renamed their copy, we have a standard and naming scheme for this exact situation. PDM helps but we have some users working outside PDM for various reasons.

Even if the structure were copied, it would never cause a problem because these other "same name" files are actually copies of the exact same file, just in a different directory. So the models even open up just fine.

I'm going to disagree here. Unless you've programmed some sort of PDM'esqe file management tool that takes "users" out of the equation, those copies will deviate. Only one of the copies can be loaded into memory. So if different copies are referenced in different sub-assemblies, it's a crap shoot which one gets loaded first. As soon as they deviate, even in small ways, you get errors or other problems that seem very random to the user.

These are large complex assemblies all with multiple configs each with different suppression states which I didn't have the time to dig through and fix. I absolutely knew what the F I was doing. If SW was willing to save the files in the first place, it should be fine with a PNG.

I'll agree that SolidWorks shouldn't allow it to save that way. Or should prompt when it can't save and there is a duplicate file in the path, because that's what is really happening, it's not saving all sub-assys because some are probably set "read-only". I would fix these problems now as fixing it later is usually far worse and more time consuming.

[Fajozo]

Hello guys. I have the same problem from start using SW 2022 (earlier I used 2019). Can you explain me how can I fix this problem because now it's frustrating me very much. I try to delete red signed files and it did't help me . I have many big assamblys with this problem so what can I do with this easiest way???

[bbokser]

@jcapriotti This is indeed a major issue, but the whole point of Pack and Go is to move all of the files in an assembly to one location while maintaining the correct references. This makes it the perfect candidate for preventing this "duplicate filename" issue, except that it doesn't actually know what to do in this situation and farts out. Dassault should add a simple interface in Pack and Go for selecting the "correct" file location to use as the reference for all files with the duplicate name going forward. This would save many users hours of headaches.

[mihkov]

Because this should never be done, ever. I would be glad PnG is preventing it from even trying to copy the structure until this issue is fixed in the files. Did I mention this should never be done, ever?

You're absolutely right. There should not be 2 files with the same name and different paths in the same project. If this is the case, you need to reconsider your approach to work.

I wrote a macro for myself which is a stripped-down Pack and Go function. It works perfectly when you need to send your entire project with branched file storage to an external engineer, without links, drawings, envelopes - only parts that are now loaded into the upper assembly. And everything is added to one folder, if the names match - the file is simply overwritten. I added the macro to the SW API section.

[zxys001]

Curious, does it help/work when using "Keep full folder structure"