Page MenuHomeAleph Objects Inc

Clear Cache answer
Closed, ResolvedPublic


On numerous tickets I see the answer to issues is 'clear the cache'. This isn't a real answer to a larger issue. If the cache is going to need to be cleared every time we make changes to Cura 2 with a new release, users are going to be running into issues non-stop.

Event Timeline

Steven created this task.Sep 15 2017, 7:11 AM

Is it possible that we can generate a new cache directory or file every time there is an update so we do not have to have the user clear the cache files?

@Steven Yes, we can use different folders for minor releases, but user wit every new update will have "clear" program, without any settings or user profiles. So, this will be not user friendly, we need find another way to solve this problem.
Ultimaker publish only major releases and provide plugins that update old settings to new, but we also use minor releases, and making new plugin every release(everyday) is very bad idea.
Maybe better to raise this issue on meeteng?

@victor_larchenko: I see that cura is actually creating


directories for every subversion. I think the problem is that some older dirs there get loaded instead of the current one. The best way that works for me is to completely remove
all these directories at every new install.

@alexei, cura creating this only for .cache but not for .config and .local/share

@alexei, if we want to completely remove cache on every install, the best way is add remove commands to installer
for linux as "postinstall" script inside .deb package
for windows to installer
not sure how it works on mac

The cache files are all stored on a per user basis. When the application is being installed it is being run as root or adminstrator. We don't know, in general, what users on the machine would want their cache files removed.

The proper solution would be to have the Cura 2 application do this when it runs. Maybe this could be done as a plugin, similar to the way the ChangeLog plugin shows the release notes when a new version of the application is run for the first time. Then we wouldn't need to modify Cura itself (assuming we can get the plugin to run before Cura reads all the settings).

We would need to know what file we want to remove. I imagine we don't want to remove the settings for the printer, custom materials, etc. Or we could just ask the user.

A simpler fix could be to just add a button somewhere in Cura that removes the cache files, probably with a suitable warning and confirmation dialog.

victor_larchenko closed this task as Resolved.Oct 19 2017, 2:51 AM
Steven reopened this task as Open.Oct 23 2017, 9:08 AM

@victor_larchenko we talked about the cache issue more last Friday and think having the cached clearing prompt is going to lead to more confusion. Can you please revert the commit with the cache clearing tool?

In discussion the real fix really needs to be dealing with profile and slicing changes between releases. I think this is something we should address in v3 so I'll leave this ticket open.

@Steven Commit reverted. Should this task still be open?

@victor_larchenko: I looked through the logs and noticed couple of crashes in cura/Settings/
The functions that were crashing were: resetMachine and isMachineChanged they both were referencing non-existent function:
_updateVariantContainer. After looking at history it was removed in rCTedd0b9c1a63f816895c0a4dc402f44117b2addd6 so
I've re-introduced it and now logs a much more cleaner than they used to be with no crashes.

I'm not sure if re-introducing this function is the right thing to do though, so could you please check it?

@alexei, it's not needed, because there is another way to check this.

victor_larchenko closed this task as Resolved.Nov 24 2017, 3:09 AM

Reopen, if it will appear again