#321 Cleanup during shutdown

v_3.x
closed
5
2013-06-04
2012-06-30
Saki Gaitatzes
No

It seems there is some cleanup that should happen after sweethome3d is closed. For example I am on a Vista system and every time I start sweethome3d (and that is about 10 times a day) a new directory is created in C:\Users\???\AppData\Roaming\eTeks\Sweet Home 3D\work\some directory\ which always has the same files in it. If sweethome generates this every time it should remove it every time. I did not know about this directory and when I checked the size on the disk it was more than 20GB of information that is not needed.

Discussion

  • This is due to Java issues reported in:
    http://www.sweethome3d.com/support/forum/viewthread_thread,1694
    Nevertheless, you shouldn't have files older than one week for a given version of Sweet Home 3D, because older files in the work directory are automatically deleted 10 minutes after program launch. I programmed this delay to allow users retrieve some files in case of a crash.

    I tested the workaround proposed by Oracle at
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962459
    but it didn't work in Sweet Home 3D circumstances.
    The main issue is still the other bug I reported at
    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962458
    and that one is still not fixed.
    Nevertheless, Java 7 might have brought some new tools that I could use to improve this problem in a future version.

    If you want to reduce the amount of files copied in the work directory, change the attributes of the sh3f files you may have in C:\Users\???\AppData\Roaming\eTeks\Sweet Home 3D\furniture to readonly. You can also cleanup the work directory whenever you want once you exited Sweet Home 3D.

     
  • I finally found how to apply in Sweet Home 3D the workaround proposed by Oracle for the Java bug #6962459. It would have been much easier if Oracle fixed the other bug #6962458 (Files tagged with deleteOnExit are not deleted when accessed with jar protocol), but strangely they deleted this bug report.
    Anyway the temporary files are not locked anymore and they can be deleted at program end when it stops normally. Many gigabytes are going to be saved, without the need to delete manually temporary files! :-)

    The bug fix will be available in the next release, but I would be pleased to read the report of your tests if you're able to run the program from the source code available in CVS. Caution: files containing some 3DS files (SH3D or SH3F files) won't be deleted until the Loader3DS 3DS import library will be updated too (hope I can do that in the coming days)

     
    Last edit: Emmanuel Puybaret 2013-04-17
  • Fixed in version 4.1
    I found a way to make it work with 3DS files too, even if updating the Loader3DS 3DS library would be more efficient.

     
    • status: open --> closed