SUMMARY Usually when working on a picture saving and autosaving takes only a bit of time. However when working on big files, for example animation, it can take a lot of time. And while one saving happens, the other is canceled. So when autosave is in progress, the user can request saving the file several times, get no indication that anything is wrong, and still not get the saved file. STEPS TO REPRODUCE 1. Have a big file. 2. Make a change. 3. During autosaving, try to perform a "Save As" or "Save Incremental Version". OBSERVED RESULT Krita accepts it and closes the dialog. There is no error messages and no saved file. EXPECTED RESULT Krita waits for autosave to finish and saves the file *or* shows an error message *or* saves both autosave and the file *or* cancels autosave and saves the file. SOFTWARE/OS VERSIONS Krita Version: 4.3.0-prealpha (git edb2c84) Languages: pl, en_US Hidpi: true Qt Version (compiled): 5.12.2 Version (loaded): 5.12.2 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17134 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 Hardware Information GPU Acceleration: auto Memory: 16191 Mb Number of Cores: 12 Swap Location: C:/Users/Agata/AppData/Local/Temp ADDITIONAL INFORMATION: Saving log: 20 Jul 2019 11:04:21 +0200: Converting from application/x-krita to application/x-krita. Location: C:/Users/Agata/Documents/intel/nextedition\.HDR_landscape_final.kra-autosave.kra. Real location: C:/Users/Agata/Documents/intel/nextedition\.HDR_landscape_final.kra-autosave.kra. Batchmode: 0. Configuration: none 20 Jul 2019 11:13:32 +0200: Saving Document C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final.kra as C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra (mime: application/x-krita). 1920 * 1080 pixels, 3 layers. 361 frames, 12 framerate. Export configuration: No configuration 20 Jul 2019 11:14:19 +0200: Saving Document C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final.kra as C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra (mime: application/x-krita). 1920 * 1080 pixels, 3 layers. 181 frames, 24 framerate. Export configuration: No configuration 20 Jul 2019 11:16:35 +0200: Completed saving C:/Users/Agata/Documents/intel/nextedition\.HDR_landscape_final.kra-autosave.kra (mime: application/x-krita). Result: OK 20 Jul 2019 11:16:56 +0200: Saving Document C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final.kra as C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra (mime: application/x-krita). 1920 * 1080 pixels, 3 layers. 181 frames, 24 framerate. Export configuration: No configuration 20 Jul 2019 11:16:57 +0200: Converting from application/x-krita to application/x-krita. Location: C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra. Real location: C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra. Batchmode: 0. Configuration: none 20 Jul 2019 11:18:05 +0200: Completed saving C:/Users/Agata/Documents/intel/nextedition/HDR_landscape_final_180.kra (mime: application/x-krita). Result: OK As you can see, only the last request was successful.
Hey tiar, is this still relevant? We did change a lot about saving last summer...
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
Still the case (and I don't think any saving changes last year were relevant; they were mostly changes in plugins for specific formats, not the general saving strategy).
*** Bug 425584 has been marked as a duplicate of this bug. ***
The duplicate bug is most probably caused by the same thing. It mentions that Export during Save doesn't work, either. Both are quite dangerous for the user, I believe.
*** Bug 435204 has been marked as a duplicate of this bug. ***
Is this still the case?
Yes, More generally (see my duplicate https://bugs.kde.org/show_bug.cgi?id=425584) you can't queue saving operations. For example you can't save and export in parallel. Only the first command will be taken. I sometimes lose quite some work because I think a save was done but was not.
This leads to sometimes uncool data loss. It's easy to reproduce so if you need me to try anything...
I've tried to reproduce this, but... I couldn't. This is what I saw happening: I set autosave to 1 minute, I saw the autosave message, pressed ctrl-s when that was visible and the autosave's save progress bar was in progress, I pressed ctrl-s, and my save started immediately after the autosave.
Here is a way to reproduce easily as this is not directly related to autosave but concurrent saving commands: -Prepare a big canvas (big enough for the saving as a png to take several seconds). -export it to png -CTRL + s before the finished saving popup appears The file is not saved (still the star in the title etc.)
Okay, I've managed to reproduce this now.
Btw, note that if you regularly want to both export and save the .kra, you can just enable the checkbox "Also save as kra" in the png export dialog.
Definitely will give it a try as I often do need that. However concurrent saving usecases are so numerous I'm glad you could reproduce.
Merge request: https://invent.kde.org/graphics/krita/-/merge_requests/1410
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1410
Git commit 45c28ddef8e09e19ce186fbfcd3ef7580ecf9ab4 by Dmitry Kazakov, on behalf of Halla Rempt. Committed on 31/05/2022 at 12:10. Pushed by dkazakov into branch 'master'. Warn the user if a save operation is aborted It's possible to try to save during autosave or try to export when a save is going on, and in that case the savingMutex is locked and we'd cancel() the saving operation, silently, as if the user had pressed cancel in the export dialog. Now we can return not just a bool, but succes, failure or busy from initiateSaving depending on whether the the document was busy, saving succeeded or failed. M +26 -23 libs/ui/KisDocument.cpp M +2 -2 libs/ui/KisDocument.h M +2 -1 libs/ui/KisImportExportErrorCode.cpp M +3 -0 libs/ui/KisImportExportErrorCode.h M +6 -0 libs/ui/KisImportExportUtils.h M +4 -3 libs/ui/KisMainWindow.cpp https://invent.kde.org/graphics/krita/commit/45c28ddef8e09e19ce186fbfcd3ef7580ecf9ab4
I'm reopening this bug, because we agreed that we need a proper save operation queueing/compression. The fix in the commit avoids the data loss, but makes UIX not very user friedly.
I'm assiging it to you :P