peso file solidworks

[strafede86]

Bye-bye.

I realized something curious, I have a part file on which I handed out enough, inside I have a twenty configurations.
the part weighs the beauty of 28mb, but with a simple operation: file saves by name part, without changing absolutely nothing and creating an identical copy the file weighs 3mb.
opening the file apparently doesn't change anything between the two...
Do you have any idea what's going on? I'm using swx 2010.

Hi.

 

[Syncmaster]

Bye-bye.

I realized something curious, I have a part file on which I handed out enough, inside I have a twenty configurations.
the part weighs the beauty of 28mb, but with a simple operation: file saves by name part, without changing absolutely nothing and creating an identical copy the file weighs 3mb.
opening the file apparently doesn't change anything between the two...
Do you have any idea what's going on? I'm using swx 2010.

Hi.

always happens and depends on the idiotic implementation of solidworks file manager.
you can't do anything about it if you don't save your files by name

 

[strafede86]

always happens and depends on the idiotic implementation of solidworks file manager.
you can't do anything about it if you don't save your files by name

But this is high technology!
but is there any data lost in the rescue process? Are files actually identical? It doesn't make any sense.

 

[reggio]

always happens and depends on the idiotic implementation of solidworks file manager.
you can't do anything about it if you don't save your files by name

bye, you might mean "if not re-Save your files by name"?

I mean, I had never tried but sometimes it happens to be found with "banal and simple" files much more fat than other "complete" files, you say that, if for example I found myself with a "corona.sldpart" file from 10mb, it would be enough to save as:

"corona_x.sldpart"

and then again in "corona.sldpart" (to maintain the same name and do not screw up inside any axioms)

to "bear" the old file and maybe take it to 5mb? Do I understand or how?

 

[Syncmaster]

bye, you might mean "if not re-Save your files by name"?

you have understood very well
and anyway you don't miss anything. It's a simple solidworks rescue algorithm problem. .

not all donuts go out with the hole:biggrin:

 

[Oldwarper]

I always knew it was the fault of windows and its indexing. However, just do a save by name, then manually delete the old file and rename, always by hand, the new one by the name of the old one. keep in mind that in case of axiemi the save by name of the components must be done with the option saved as a copy, to maintain links with old file names.

or make a packandgo of the files in another directory and then copy them all in the old dir. eye not to delete all the previous files, but overwrite with those saved (some file references can "expel" to the packandgo).

remains always a question of caprine wool, to be done only in cases clamorously difficult or problematic.

 

[re_solidworks]

you have understood very well
and anyway you don't miss anything. It's a simple solidworks rescue algorithm problem. .

not all donuts go out with the hole:biggrin:

I would say they often manage with several holes....

 

[meccanicamg]

as it happens with almost all 3d modelers you have that the continuous rescue with the save key adds incrementally the data by hanging them in the queue to the file itself. saving by name is disassembled the file and saved only with the actual data of the model, eliminating the various deposits that were generated at every saving operation.

 

[marcof]

as it happens with almost all 3d modelers you have that the continuous rescue with the save key adds incrementally the data by hanging them in the queue to the file itself. saving by name is disassembled the file and saved only with the actual data of the model, eliminating the various deposits that were generated at every saving operation.

I remember having used the program "unfrag" successfully and without particular problems for a while, despite the fact that solidworks did not recommend the use for I don't know what reason.
Now I don't care about the size of the files anymore, ecchecavolo, I can't be behind all the programmers' turbs. I prefer to change hd when it becomes insufficient :redface:

 

[maxopus]

as it happens with almost all 3d modelers you have that the continuous rescue with the save key adds incrementally the data by hanging them in the queue to the file itself. saving by name is disassembled the file and saved only with the actual data of the model, eliminating the various deposits that were generated at every saving operation.

what almost that makes the difference... :smile:

 

[marcof]

what almost that makes the difference... :smile:

I'm sure I'm wrong, but I think I'm vaguely noticing, but just a very light hint between the lines, which pro-and does not "wrap" the files. :smile:

 

[maxopus]

I'm sure I'm wrong, but I think I'm vaguely noticing, but just a very light hint between the lines, which pro-and does not "wrap" the files. :smile:

What makes you think?

 

[cacciatorino]

What makes you think?

but engineer/professionist does not do par.1, par.2 par.3 etc. etc. ongi volta che salvi? Maybe even solid works have a system of internal versions to the file so it tracks previous saves.

 

[maxopus]

but engineer/professionist does not do par.1, par.2 par.3 etc. etc. ongi volta che salvi? Maybe even solid works have a system of internal versions to the file so it tracks previous saves.

you engineer/professional saves a new file to each save (if the file has been modified).
I don't know if you work hard work in the way you're reported.

 

[marcof]

engineer/professional....

but think of you, and I always believed that the real name of the soft-component you use to design was "for the engineer" and not "engineer-professionist".
it is seen that to the granite-one the Latin has not gone to make it understand:tongue:

 

[maxopus]

but think of you, and I always believed that the real name of the soft-component you use to design was "for the engineer" and not "engineer-professionist".
it is seen that to the granite-one the Latin has not gone to make it understand:tongue:

are Anglo-Saxons, it's been too long since Roman domination, what do you want me to remember Latin :biggrin:.

 

[re_solidworks]

It is true that the files of proes are very light and at each rescue the fies are recreated. apart from that then the user touches the wrong task of keeping the archive decently clean, I noticed that despite the lightness when copying/setting the files generated with proe the copy performance of windows collapse.
to keep in mind that I usually carry out these shifts with xcopy, so without waste of resources for graphical frills and remaining time calculations.

 

[SolidUser]

always happens and depends on the idiotic implementation of solidworks file manager.
you can't do anything about it if you don't save your files by name

It has nothing to do with solidworks, it is necessary to inform yourself before firing judgments.

 

[SolidUser]

you have understood very well
and anyway you don't miss anything. It's a simple solidworks rescue algorithm problem. .

not all donuts go out with the hole:biggrin:

but what algorithm.... but did you invent them or did some technicians tell you?

 

[SolidUser]

files increase for various reasons :
1) configuration
2) changes (storic windows)
3) previews for each configuration activated and linked to document resolution
4)
5) motion
6) pv360
7) virtual components
....
the cases are various and others besides my mentioned.