Print at May 28, 2022, 9:14:36 AM

Posted by mazoola at Jan 6, 2016, 12:46:34 PM
Re: Suddenly, huge file size...
Well, that description certainly applies to my current 'double-stuffed' project: ContentsDigests entry 61 contains a reference to texture.png -- and directory /61 contains the recursively saved house plan.

Is there a way to determine which object(s) contain the offending texture? In mentally retracing the steps leading to the corrupted save, I can't recall adding any texture-containing objects to the plan. (As best I can remember, the only new objects since the previous, non-corrupt save were light sources I copy/pasted from the save level.)

The only seeming constant I've found so far has had to do with time since last save -- which is partly why I asked about autosave. In every instance I can recall, a corrupted save occurred only when I'd been working on a unsaved plan for longer than, say, 20 minutes. Not all prolonged work times resulted in a bum save, but I've not yet saved a file open less than 15 - 20 minutes and had it double in size.

Also, in an earlier reply you said

The ContentDigests entry in a .sh3d file gives the SHA-1-Digest value of every entry of the .sh3d file used by Sweet Home 3D. This value is used to quickly check whether an entry is correct or not. So if you edit an entry in the .sh3d zipped file, Sweet Home 3D will think the file isn't correct anymore. I didn't program this feature to avoid users to manually edit an .sh3d file of course, but to check if an error on the disk didn't happen and inform the user accordingly. If you want to bypass this data integrity check, just remove the ContentDigests entry of a .sh3d file before opening it with Sweet Home 3D.

---which suggests to me that I should be able to save-and-compress a corrupted design, open the compressed .sh3d file in an archiver, delete the spurious directory, delete ContentDigests, and load the modified .sh3d file. When I try this, SH3D starts to load the plan but then pauses with a 'remove, replace, or halt' warning. If I respond with either remove or replace, the app simply stops the load. This occurs with the offending directory removed or merely left empty and with ContentsDigests deleted or merely edited to remove any reference to the directory. Am I missing something here? Being able to hack the plan back to size and not lose the time worked since the previous save would be of great benefit -- even if I had to reimport and position an object.