Problem saving to Local Temp folder

Hi all

I'm having a problem that I can't explain: 

Solidworks saves some files (in this case the pipes in routing assemblies) here: C:\Users\sdevauchelle\AppData\Local\Temp\swx13176\VC~~ (see attachment)

However, I don't use automatic backups because I prefer to back up regularly manually.

It seems that these temporary files are regularly deleted and I lose all the tubes of my routings...

In short, I don't understand why suddenly the tube files point to a temporary folder. 

I've already done the trick of replacing these parts by pointing to the right design library file, but a few days later, the tubes have disappeared again and are pointing back to the temporary folder.

Does anyone know about this problem? 

I'm in SW2021 SP05.

Thank you.

 


screenshot_1952.png
screenshot_1951.png
screenshot_1927.png

Hello

Problem setting routing paths? You should look at Solidworks Routing Library Manager if there is not a problem in the settings.

I went around the Routing Library Manager, everything seems ok.

I would like to point out that, when creating a routing subassembly, the parts that are pipe fittings point to the design library folder, but for the parts files that are tubes, solidworks saves as a virtual part of the subassembly...

Hello

Your parts are virtual files (so saved IN the assembly): the small  ^ in the file name.

Their location is normal.

On the other hand, you must save the ASSEMBLY before closing everything to avoid losing modifications.

 

 

1 Like

Thank you for the answers.

We agree: virtual files represented by ^ , so saved in the assembly. And that's where it gets stuck: they (sometimes) register in the temporary folder (above)... File that ends up purging automatically, so we lose all the parts that are supposed to be virtual....

Normally, virtual files work fine.

We work a lot with this and the number of bugs is limited (or even almost non-existent except possibly in case of opening duplicate files simultaneously: it can happen that SW mixes the brushes in this case).

On the other hand, forgetting to save the ASSEMBLY containing the virtual files is a common mistake among those who are not used to virtual files. If the assembly is not saved, neither are the virtual files.

SW always opens (and therefore saves) virtual files in a temporary directory.

Seeing your last screenshot it seems that SW has lost the virtual reference to reference only the local file saved in the temporary working directory.

Normally it should be like this:

The path of the virtual file should refer to the assembly, not the local temporary directory (which seems to be the case given your screenshot).

You can possibly check this before closing the assembly (and resave the file locally before revirtualizing it if you ever have a path to your local directory).

After that, it is possible that the 2021 Sp5.0 will be bugged on this specific point (if this is the case I would stay with my 2020 sp 3.0 bugged to death..)

 

 

2 Likes

Thank you froussel for this precise answer.

In PC, a normal operation that is compliant. I have taken note of your remark about the registration of the assemblies, normally I proceed well as you describe, I will be vigilant in the future.

What's funny (or not) is that my colleague encountered a similar more serious case (he lost all the Pipe assembly because it was set up as a virtual subassembly) almost at the same time as me (we each work locally). He tells me that he opened the assembly for a dimension survey, closed without saving, and, the next time he opened, his (virtual) routing subassemblies had disappeared and pointed to the same non-existent temporary folder. 


screenshot_1959.png

Hello

Let's see if routing doesn't have a problem on the 2021. I have a ticket in progress for another problem with accessories in a state of removal impossible to reactivate (with each rebuild they disappear, not to mention the routing sketches that can be rebuilt in any way)

And these accessories point to which backrest? 

The length of (virtual) file names and assemblies can be a problem in the end (limitation of windows path lengths)

Indeed it is a point to check as well as the length of the access paths... But if it did, the problem would appear on other assemblies? 

Not necessarily if in other cases you are below the limit... (it only takes one more character to eventually make a mess)

In your assembly: right click on the virtual part then property and copy/paste the "path of the model document" and count the characters. (NBCAR()  does it very well for you in Excel)

If you exceed 255, this could explain it.

1 Like