If I reply to this will the NSA be knocking on my door?
I'm too innocent of a guy to know what you are getting at, but EPDM isn't doing anything to the files other than storing them, manipulating their read/write status on the local client, and any edits a linked variable on a data card may do. (There is an option to zip older versions of files on an archive server...but if you don't have this option on, it is just simple storage)
Otherwise, any file changes will happen when the application accesses the file.
If anyone is tapping my phone, I'm not a spy.
I can't directly answer your questions, but I think I can answer #2. We don't use any other type of file management here other than storing them in Windows Explorer, and my file sizes were radically reduced in SW2015 also. Why the folks at SW reduced them I don't know, other than I suspect it improves performance for people that don't have the most robust computers. Again, I'm not any kind of computer expert, so that is only speculation.
And Jeff, I'm wearing my aluminum foil hat. You might want to get one too.
Jeff & Glenn...hahahah...call me Mr. Paranoid
Tin hats off (but not the gloves, just yet).
I was just reluctant to accuse anyone of introducing a compression utility into any save/load actions.
But.......as I have just open Pandora's proverbial, a way of reducing file size would be to do just that, introduce a method of compression...there are others, but to get gains of 30-60%...let's stick with it.
If a 3rd party organization were to introduce a method of file compression into my data set, I think I would like to have been informed, or consent requested beforehand, as compression is an archiving technique and isn't something you would want to run regularly on active data as corruption can be introduced.
So, onto the SW2015 file type, which as we all know, after upgrading your data set, produces a significantly smaller than previous EPDM vault.
No-one else concerned at what is happening here? It is our data after all, and I think we have a right to be told (trade secrets pending).
We know that a 'small delay' has been introduced when opening and saving files (what do you think could be causing that?).
I'm also extremely interested to be told whether this 'data size reduction technique' happens at the client end, once that file is transferred to it, or at the server end and then the full-size file transferred to the client workstation. Is my EPDM server being caned twice on the same file each end of a load/save?
Everyone just seems to have accepted this without asking any questions; well i'm asking because i think it's important to know what is happening to our data, and our hardware infrastructure.
I take it you've read this - SOLIDWORKS 2015 – The How & Why of Reduced File Sizes #solidworks #sw2015 | Michael Lord
Someone could just tell me that there is no compression routine involved, couldn't they?
I'm not a designer (since 1998), I'm an I.T. systems admin with specific MCAD/ECAD/PDM administration and support responsibilities, so I should be asking these questions.
Over to ......
(hats back on, mines furry as it's getting colder....tin lined.)
Starting with SW2015, SOLIDWORKS abandoned the use of Microsoft Structured Storage and Compound File for their file format. Compound files have long been maligned as overly complicated and bloated. I suspect that this is the prime reason why files have gotten smaller.
+1 for Jim, that's exactly what happened to the files and it for sure caused a bunch of issues in the early SP's, especially with EPDM
Thank you for posting that link. I thought it answered a lot of your questions, and it did mention "Trade Secrets" at one point, so I suspect that's all the answers you're likely to get. I have wondered if the stability issues some people had with SW2015 was related to the file size reduction, but speculation is all it is. And to be honest, since they seem to be getting those issues smoothed out I think it was worth the trade-off. Of course I never had much trouble with SW2015, so others may feel differently.