|Summary:||Autosave stops doing its work in certain conditions|
|Product:||[Applications] krita||Reporter:||David REVOY <info>|
|Component:||File formats||Assignee:||Krita Bugs <krita-bugs-null>|
|Latest Commit:||https://commits.kde.org/krita/93bc74110edbc8c9458c9cbd8ed5d1adb6c25c86||Version Fixed In:|
Description David REVOY 2018-04-18 18:06:05 UTC
Hi, I can reproduce here a dangerous bug here with 4.0.1appimage on Kubuntu 17.10 ; one situation where autosave stops to work. To reproduce: ============= 1. Open Krita, and go to settings; put autosave to a low value to ease reproduction of the bug (3min) 2. Open your filemanager, find a *.kra file, right click "Open with Krita" 3. Paint a couple of stroke 4. (wait 3min) in your file explorer ( with unhidden files ) you should see an autosave file. 5. Now, save your file (Ctrl+S, autosave hidden files get removed) do two stroke 6. (wait 3min...or more...more...more) and check your file explorer. Result: ======= No autosave file is created passed the first save. I could reproduce three time with various files. (the first time was painful; I lost 40min of work on a panel after a crash of the transform tool). Note: Not reproducible on GIT~master of today( 2018-04-18 : 20h00 Paris Time ), autosave works correctly on it with the same scenario, only for 4.0.1appimage.
Comment 1 David REVOY 2018-04-18 19:10:05 UTC
Further test: This bug doesn't affect Krita 4.0.0appimage ; so it's not something common to all 4.x series when "appimaged". I'll turn this bug to "Resolved" because it is fixed in Git~master and affect only 4.0.1 . I'll switch back to 4.0.0 or Git~master because having a working autosave can save my productivity in case of unexpected crash.
Comment 2 Kenneth Evans 2018-07-09 03:01:10 UTC
Something similar happened to me with 4.1 just now. Krita crashed, and I lost about 45 min. of work. There was no prompt to open the autosave on restart. My Krita is set to autosave every 5 min (probably the default). I have the last .kra file at 8:26 pm. The last kra~ is at 7:45 pm, and there is no kra-autosave.kra in the document directory. This is on a Surface Book with Windows 10 64-bit. On looking at the directory with the file, I see other .kra files that I closed normally have no autosave. In fact, most do not. There are none in %temp% either. There is a krita-opengl.txt file in temp at 9:22, about the time of the crash. The contents are: ntel, Intel(R) HD Graphics 520, 3.0.0 - Build 188.8.131.5211 (Yes, the I in Intel is missing.) I am not having problems with Krita crashing. I apologize if I misunderstand Krita's autosave, but it doesn't appear to be working.
Comment 3 Halla Rempt 2018-07-09 11:45:38 UTC
All autosave files get removed if a file is saved normally. Note that there is a difference between a backup file (.kra~) which is copy of the last saved state that gets created when saving and an autosave file, which is hidden by default.
Comment 4 Halla Rempt 2018-07-09 12:40:29 UTC
Kenneth, were do you save your files? Is that an ordinary folder, or a dropbox/one drive/google driver folder?
Comment 5 Halla Rempt 2018-07-09 12:41:26 UTC
Deevad, after we closed the bug during the sprint, have you seen it again on Linux?
Comment 6 Halla Rempt 2018-07-09 13:05:50 UTC
15:05:21 <@deevad> Ok: I could reproduce the failing autosave: it needs a first manual save (ctrl+s) that remove the autosave files. After that, no other autosave are generated with this option. I have many repetitive line in the terminal
Comment 7 Dmitry Kazakov 2018-07-09 14:37:16 UTC
Git commit af6febcd63d92c6b840fd79abfef637e7e9bb4c7 by Dmitry Kazakov. Committed on 09/07/2018 at 14:20. Pushed by dkazakov into branch 'master'. Fix activation of the autosave timer after modify+save+modify cycle There were two problems: 1) modifiedAfterAutosave should be reset false every time we mark the image as clean. Otherwise it may keep the old value 2) modifiedAfterAutosave value should be used **only** for the autosave slot entry. For restarting the time we should ask the timer itself M +3 -9 libs/ui/KisDocument.cpp M +0 -3 libs/ui/KisDocument.h https://commits.kde.org/krita/af6febcd63d92c6b840fd79abfef637e7e9bb4c7
Comment 8 Halla Rempt 2018-07-09 14:55:48 UTC
I've started new builds: build 56: https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/ build 52: https://binary-factory.kde.org/job/Krita_Stable_Appimage_Build/ Please test them when they are done.
Comment 9 Halla Rempt 2018-07-09 15:09:20 UTC
Git commit 93bc74110edbc8c9458c9cbd8ed5d1adb6c25c86 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 09/07/2018 at 14:40. Pushed by rempt into branch 'krita/4.1'. Fix activation of the autosave timer after modify+save+modify cycle There were two problems: 1) modifiedAfterAutosave should be reset false every time we mark the image as clean. Otherwise it may keep the old value 2) modifiedAfterAutosave value should be used **only** for the autosave slot entry. For restarting the time we should ask the timer itself M +3 -9 libs/ui/KisDocument.cpp M +0 -3 libs/ui/KisDocument.h https://commits.kde.org/krita/93bc74110edbc8c9458c9cbd8ed5d1adb6c25c86
Comment 10 Kenneth Evans 2018-07-09 15:24:21 UTC
Looks like it's being taken care of, but to answer your question, I am saving to Documents\Krita on the local C drive. It is my understanding the autosave files should be in %temp%, which is in the standard place under AppData. There were none there, at least for the last few days. Hopefully, these don't get destroyed when you reopen the file after a crash, as the location is something I may not remember, and it takes a little research to find the location is %temp%. Reopening the last good copy is a natural thing to do first. Thanks.
Comment 11 Halla Rempt 2018-07-09 15:33:00 UTC
Autosave files for files that already have a filename are in the same folder as the file.
Comment 12 Kenneth Evans 2018-07-09 16:44:04 UTC
Thanks. That seems like a good idea. That is not what the manual says, though. It is a bit terse on the subject, as well.