 |
Eine Frage taucht immer wider auf: warum ändert sich manchmal sprunghaft die Dateigröße auf das Doppelte oder auch auf die Hälfte, wenn ich ein SolidWorks Dokument unter neuem Namen speichere? Und warum kann SolidWorks nicht schon von sich aus solche Mechanismen wie Unfrag selbst anbieten? |
Wie viele andere Dokumente (z.B. von MS Office) auch ist ein SolidWorks-Dokument ein sogenanntes Compound-File, in dem in verschiedenen sogenannten Streams und Storages Daten nebeneinander in einer Datei gespeichert werden können. So werden z.B. von SolidWorks selbst sowohl die Parasolid-Daten, als auch z.B. das Vorschaubild, die Display-Daten (die vom Viewer oder im Nur-Ansicht-Modus von SolidWorks benutzt werden) oder auch die eDrawings-Daten (wenn die Option eingeschaltet ist) in die Datei geschrieben.
Zusätzlich gibt es zwei Mechanismen, die die Dateigröße weiter anwachsen lassen:
Wie aber können nun Tools wie Unfrag oder EcoSqueeze diese Dateien wieder so klein machen und warum baut SolidWorks dies nicht optional beim Speichern ein?
Nun, die Erklärung nach dem Wie ist einfach: Unfrag kopiert alle als "benutzt" gekennzeichneten Streams in eine neue Datei und überschreibt dann die Originaldatei. EcoSqueeze tut zunächst einmal dasselbe, kann aber zusätzlich noch bei SolidWorks Dokumenten das Vorschaubild und auch die Displayliste entfernen, wodurch deutlich über 50% der Dateigröße eingespart werden können.
Diese Zusammenhänge und warum SolidWorks dies nicht standardmäßig einbaut wird im Knowledgebase-Artikel 157547 erklärt (im Kundenbereich auf http://www.solidworks.com/swdocs/Support/Subscription/html/): die von Microsoft eingebaute Technik des Shadowing dient der sauberen Abwicklung des Speichern in Compound-Dateien. Die Shadowdaten dienen der automatischen Fehlerbehebung, schützen vor Datenverlust bei unerwartetem Terminieren der Anwendung oder Umgebung und können u.U. auch zur Datenrettung bei korrupten Dateien herangezogen werden.
Durch diese transaktionsgesteuerte Art stehen die neu geschriebenen Daten erst dann zur Verfügung, wenn die Änderung auch bestätigt ist (vom
Betriebssystem). Dadurch wird erreicht, dass die Datenkonsistenz immer gewährleistet ist. Es hilft bei der Fehlerbehebung und stellt sicher, dass die vorhandenen Daten (die in Ordnung sind) nicht verloren gehen oder überschrieben werden. Zusätzlich verhindert es Datenkorruption bei unerwarteten Abstürzen der
Software (ja, ja, ich weiß, aber das funktioniert auch bei den erwarteten
Abstürzen 
), da die Transaktion des Speicherns nicht bestätigt wurde und dadurch noch die Originaldaten als aktiv gelten. Ferner werden Probleme durch "Nicht genügend Speicherplatz vorhanden" ausgeräumt (da auch hier das Speichern nicht bestätigt wird) und es werden Problemen vorgebeugt, die beim Speichern auf Netzlaufwerke gar nicht erst auftreten zu lassen.
Warum wird dann aber nicht einfach die Methode von Unfrag oder EcoSqueeze benutzt? Also eine temporäre Datei erzeugen und bei erfolgreichem Erzeugen dann die Originaldatei überschreiben? Hier gibt es einige Vorteile des Compound-Verfahrens:
Da der Moment des Speicherns die größte Gefahr in bezug auf korrupte Daten darstellt, soll nicht das zusätzliche Risiko mit der Technik der temporären Files eingegangen werden. In einem Gespräch am Rande der SolidWorks World Conference 2002 wurde mir dies auch bestätigt.
Das Unfragen beim Speichern würde eben mehr Zeit kosten, aufgrund der zusätzlichen Datenmanipulationen größeres Potential für Datenkorruption bedeuten und durch das entfernen des Shadows die Möglichkeiten des Recoverns der Daten entfernen. Das bedeutet unterm Strich, dass Geschwindigkeit und Sicherheit durch ein mehr an Speicherplatz erkauft werden.
| Kritik und Anregungen bitte an Stefan Berlitz. Letzte Änderung dieser Seite am Donnerstag, 01. Februar 2007 17:40 |