It’s a plugin which replaces Krita’s odd built-in autosave functionality, which for some unexplainable reason will delete your autosaves, with a version that doesn’t do that. It makes a docker that you can use to toggle oughtasave on or off, but it also has a settings tab where you can easily set it to autostart and from then on run in the background. So you only ever really need to look at the docker once to tune the settings as you want, if you don’t want it cluttering up your workspace.
4 Likes
Welcome to the forum! Thanks for sharing the plugin.
The autosave file is only deleted if you manually save your file successfully. So autosaves are meant for an event when there is a crash and you hadn’t saved manually. Then there are backup files which will give you last version (or any number of last version you have configured) these get created when you save. Autosave files and backup files are different. Read more about it here - Saving, AutoSave and Backup Files — Krita Manual 5.2.0 documentation
If krita is deleting autosave file before you manually trigger a save then it is a bug please report it. The autosave files should only be deleted when you actually save at which point you already have a saved file thus making autosave files redundant.
When krita closes, it automatically deletes the autosave it has generated. Unless krita has crashed, in which case it gives the option to reload from the autosave. My understanding is that this is not a bug but an intentional feature. Here’s an example from a previous thread:
Yes when you close krita without saving it prompts you to save. If you intentionally close krita without saving then it is a user choice.
Autosave is not meant to be accessed by user. it is for krita it is only known to the user by means of the settings page.
Perhaps you are wanting to trigger something like manual save automatically with the plugin in case user is not saving or in case of accidental “intentional” click on “don’t save” button by user without thinking while closing krita?
I am sorry for asking questions, the plugin may help for those who need it. I am trying to understand what problem it solves and in what scenario this plugin helps and if it can be solved natively too in future. Since losing file is data loss and users shouldn’t be relying on plugins to solve data loss issues.
The main issue is that Krita’s definition of a crash doesn’t match my own. If krita soft locks rather than hard crashes, then shutting it down counts as shutting down the program, and it deletes the autosave. However, because it is soft locked, it doesn’t allow you to save. I have also had it shut down when, for example, opening a file dialog or attempting a filter operation that krita didn’t like- but it seems to have handled itself well enough to shut itself down instead of crash outright, thus deleting the autosave.
I have had it happen where an autosave itself is what seems to softlock krita for whatever reason- probably because I tried doing a filter or other intensive operation at the exact same moment. Since krita is soft locked I’m in the bind of watching Krita attempting to save itself and not being able to save my work, knowing that as soon as I turn krita off it will delete everything.
Also, for any reason- tiredness, the pop-up didn’t work for them, they reflexively hit a dialog choice without looking- users sometimes make mistakes and ignore dialogs, which could lead to hours of wasted work. Especially if they misunderstand ‘autosave’ to mean ‘saves automatically’, and not ‘crash prevention recovery’, and so they assume they are losing the last X minutes of work since the program last autosaved, and not the entire session since they never saved manually. This is a mistake people will only make once but it still represents lost work.
Thanks for this explanation. This seems to be a problem because in case of krita being killed by Operating system there should be an autosave file if it is not happening then it is a bug. Autosave if triggered in scheduled time only should be deleted if user saves manually. And in case of autosave itself crashed or krita crashed while autosaving then it needs to be investigated too. I do not understand how your plugin will behave differently here it too needs to save and if Krita is locked how it will save how does this plugin behave differently. In case krita crashes or locks itself your plugin won’t be able to make the save too.
Then perhaps the official naming should be changed to recovery-file instead of autosave.
With regards to user error due to tiredness or lack of attention then it can only be solved by user themselves.
All I am saying is if there is a shortcoming (which your description of plugin readme in github and here implies) in the mechanism of this important feature which results in data loss it should be fixed in the core, while your plugin may provide a workaround now, but it seems bad to depend on a third party plugin for this main feature.
In anycase I will not bore you with my long messages. If you feel there is a shortcoming and issue with core functionality please report a bug so that it improves and helps everyone even users who may not know about your plugin and not have it installed.
1 Like
That’s true, however I would only be losing the amount of work since the last autosave- Krita does include a system to cycle between a main save file and a backup previous save, which is handy. The main advantage to a system that simply saves automatically, especially where you can set X number of back-up saves, is that you can always be assured that in the worst case scenario you can only possibly lose so much work dating back to the last good autosave, unless every single save file is corrupted simultaneously.
My impression of previous forum posts and bug reports already reported by other users is that Krita is working as intended, because having multiple saves per file will clutter up your hard drive. I can understand the logic behind this, although I’d rather sacrifice hard drive space for security and peace of mind, so I just wrote up my own little script to get the implementation I wanted. But in the morning I’ll submit a bug report.
Which operating system and ‘shut down’ method are you using?
If I ‘End Process’ or ‘Kill Process’ on Linux then the autosave file is not deleted.
That is what I asked earlier are you trying to trigger a type of manual save for the user, so instead of users pressing ctrl + s themselves this plugin does it for them periodically. if that is the case then neat plugin but the description may need to state that part too.
In any case the earlier issue of krita soft locking and autosave getting deleted and the naming issue which confuses users should be reported .
Re-reading the git page, it does come off a bit combative. I can rewrite the description a bit to be more clear about what it does and lose the tone.