https://bugs.kde.org/show_bug.cgi?id=498257
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Version First|unspecified |5.2.12 Reported In| | Status|REPORTED |CONFIRMED CC| |[email protected] Ever confirmed|0 |1 Keywords| |triaged --- Comment #2 from [email protected] --- The errors Dmitry mentioned are fixed, but you can still pretty easily corrupt a file with the following steps to reproduce: 1. Save a file that takes a while to save. 2. Go into the application overview and swipe Krita out of the way so that it terminates. 3. Try to reopen the file, see that it won't work. Of course #2 is likely to happen in practice in the form of Android deciding that it would really like to reclaim memory while Krita is saving and the out-of-memory killer kills it dead. I assume the reason this happens is because Krita writes directly to the output file, given that Android has no support for QSaveFile, so it just truncates the file first and starts writing it in-place. That means there's an immensely long span of time where the OS getting impatient will guarantee total data loss, both of the old file and any changes made meanwhile. That could be solved by writing the file to the internal application data first and then once that has succeeded copy it over the original file. This isn't perfect, because Android can't do an atomic move of a file like a real operating system could, but just shoveling data over is so fast that it's pretty unlikely for the application to be terminated in that exact moment. Alternatively, Krita could first back up the old file to the internal application data and then start saving, then detect whether that got interrupted on the next startup and offer to recover the file. This would never leave you in the situation where neither the old nor the new data are persisted anywhere, but downside is that it's a whole lot more work to implement, to the point where it's questionable whether it makes sense to bother with it at all over implementing the save to sandbox instead, cf. https://invent.kde.org/graphics/krita/-/issues/20 In both cases, you'd still lose your current changes of course, since Krita is terminated before it can save that, but it would at least retain the old state. -- You are receiving this mail because: You are watching all bug changes.
