Created attachment 140622 [details] Animated GIF screencast that visualizes Reproduction Step 2 SUMMARY Creating a color palette with the checkbox for embedding the palette into the document set corrupts the KRA file after saving. Once the KRA is saved, Krita closed and opened again, the KRA file cannot be saved anymore. At all. STEPS TO REPRODUCE 1. Create a new document. 2. Create a new Color Palette (e.g. "BuggyPalette" for both name and filename) and tick the checkbox for embedding the palette into document. 3. Save your project file as .KRA, (e.g. "TestFile.kra") 4. Close Krita. 5. Open Krita again. 6. Load your project file. 7. Paint something (or make any other change to your file so you have something to save). 8. Try to save your file via CTRL+S / File>Save or File>SaveAs... OBSERVED RESULT The file has become corrupted and cannot be saved anymore. A dialog is shown with a different error message, depending on which save option you used: File/Save = "Could not save [XXX.kra] Reason: Unknown Error" File/Save As... [different file name] = "Could not save [XXX.kra] Reason: Error occurred while writing to the file" EXPECTED RESULT The file should save successfully without any errors. SOFTWARE/OS VERSIONS Windows: Win 10 Pro 21H1 / 19043.1110 Krita version: 4.4.7 (x64 windows installer) ADDITIONAL INFORMATION - I attached an animated GIF screencast that visualizes Reproduction Step #2. - Workaround: Renaming the .KRA file to ZIP and manually deleting the corresponding palette file (palettes/BuggyPalette.kpl in this case) seems to fix the save bug, even when the (now missing) palette is still referenced in maindoc.xml . Not sure if there are any side effects to this, though.
Could you please check if the same happens on Krita 5.0-prealpha (available on Krita website, it's called "Krita Next")? It would really help. (Make sure to backup your resources and configuration before doing that; though danger of losing anything is not high).
Created attachment 140623 [details] Error Log of the failed save operation (after Krita was re-opened and the corrupted KRA file was loaded)
Hi :) I've tried the portable 5.0-prealpha thingie. Trying to overwrite the file (CTRL+S or File>Save) still throws an error message, but it's a different one than in Krita 4.4.7: ================================================================================ SESSION: 10 Aug 2021 00:58:58 +0200. Executing Z:\DOWNLOADS\Firefox\_Programs\krita-nightly-x64-5.0.0-prealpha-ddac595d6e\krita-nightly-x64-5.0.0-prealpha-ddac595d6e\bin\krita.exe Krita Version: 5.0.0-prealpha (git ddac595), Qt version compiled: 5.12.11, loaded: 5.12.11. Process ID: 19020 -- -- -- -- -- -- -- -- 10 Aug 2021 00:58:58 +0200: Style: fusion. Available styles: windowsvista, Windows, Fusion 10 Aug 2021 00:59:17 +0200: Non-store package - creating updater 10 Aug 2021 00:59:27 +0200: Importing application/x-krita to application/x-krita. Location: Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra. Real location: Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra. Batchmode: 0 10 Aug 2021 00:59:27 +0200: Loaded image from application/x-krita. Size: 3508 * 3508 pixels, 4.16667 dpi. Color model: 8-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 14 10 Aug 2021 00:59:33 +0200: Saving Document Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra as Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra (mime: application/x-krita). 3508 * 3508 pixels, 14 layers. 101 frames, 24 framerate. Export configuration: No configuration 10 Aug 2021 00:59:33 +0200: Create a simple backup for Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra in the same location as the file. 10 Aug 2021 00:59:34 +0200: Converting from application/x-krita to application/x-krita. Location: Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra. Real location: Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra. Batchmode: 0. Configuration: none 10 Aug 2021 00:59:35 +0200: Completed saving Z:/3D Stuff/_Krita/shirt_michi_holger_NEW.kra (mime: application/x-krita). Result: Cannot open file for writing. Reason: The file could not be copied.. Size: 6922637. MD5 Hash: 7ea936a1f960ac531b27fa8283b7a729 10 Aug 2021 00:59:57 +0200: CLOSING SESSION ================================================================================ Other files (without embedded palettes) are overwritten in 5.0-prealpha without this error, so it shouldn't be missing priviledges or something. When saving the project file under a new filename however (Save As...), the file is saved successfully and can then be overwritten by Krita 5.0-prealpha even after restarting it. Also, creating a new document-embedded palette on 5.0-prealpha appears to work without corrupting the file - at least on 5.0-prealpha. This new file is still bugged for Krita 4.4.7, though. So my guess would be that Krita 4.4.7 makes some kind of mistake at the time it loads a file with an embedded palette, which completely prevents it from saving this file at all? Also, any files with palettes that are saved on 4.4.7 appear to produce a "corrupted" one that only 5.0-prealpha can successfully "save as" a new file but still NOT overwrite. TL;DR KRA file with embedded palette created and saved by 4.4.7: - cannot be overwritten by 4.4.7 - cannot be saved as new by 4.4.7 - cannot be overwritten by 5.0-prealpha - CAN be saved as new by 5.0-prealpha KRA file with embedded palette created and saved by 5.0-prealpha: - cannot be overwritten by 4.4.7 - cannot be saved as new by 4.4.7 - CAN be overwritten by 5.0-prealpha - CAN be saved as new by 5.0-prealpha
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Hm, I can save a krita4 document with an embedded palette after editing the palette.
I have tested the bug in Krita 5: I can save the document after creation of an embedded palette, there is no error. **But** when loading the document, the embedded palette does **not** show up in the list of palettes.
When testing in Krita 4.4.7, the embedded palette is save and loaded correctly. Though in 4.4.7 there is a different bug. The palette doesn't disappear when I close the document :)
(In reply to Halla Rempt from comment #5) > Hm, I can save a krita4 document with an embedded palette after editing the > palette. I just tried editing the embedded palette (by adding another color to an empty slot and also changed the number of slots from 16 to 15), but the file still doesn't save. Have you restarted Krita and reloaded the project file after saving? And did you make a stroke or something before trying to save so Krita marks the file as "changed"? When I create an embedded palette in a clean file, I can still overwrite and "save as..." for the rest of the session. But as soon as I close Krita, the next time I re-open Krita and load this file, I cannot save it anymore. Which is why I was thinking that it's more of a loading issue. @everyone I will attach a new .kra test file that I just created in 4.4.7. Only thing I did was create an embedded palette and saved it. If I'm correct then you should not be able to make a stroke and overwrite it (4.4.7 and 5.0-prealpha) or save as new (4.4.7).
Created attachment 140631 [details] New project test file with embedded palette, saved from 4.4.7 - I am unable to make a stroke and save it.
(In reply to Dmitry Kazakov from comment #6) > I have tested the bug in Krita 5: I can save the document after creation of > an embedded palette, there is no error. **But** when loading the document, > the embedded palette does **not** show up in the list of palettes. I noticed (after renaming the .kra file to .zip and viewing the archive's folder structure) that the test file I uploaded (paletteBugTestFile2.kra) saved its palette in "unnamed\palettes\newBuggyPalette2.kpl". After loading the file, the palette is hidden and Krita can't save the project file. The file where I originally experienced this bug, though, (shirt_michi_holger.kra) saved the palette under "shirt_michi_holger\palettes\_MichiShirt.kpl" and not "unnamed\...". For this file the palette IS shown, but it still can't be saved either. So a hidden palette might be somewhat related, but not necessarily the cause for the save issues.
I do see the palette embedded in a krita5 file both in the database as well as in the palette docker's palette selector. Anyway, I will take this bug and see what I can do.
This is a regression in Krita 4.4.5, probably from commit a7458f988ba563b12ef371969c31fba4620e1bca Author: Agata Cacko <tamtamy.tymona@gmail.com> Date: Fri Jun 4 20:26:01 2021 +0200 Add more checks on saving to kra (no new strings) Before this commit, lots of functions that returns bool signalizing an error had their return value ignored. This commit adds additional checking of the return value. Cherry-picked from c29b9b5668, but edited to not contain any new user strings.
Git commit 6551d98964c03978c0b9ce926e61498ac901f26e by Halla Rempt. Committed on 12/08/2021 at 09:45. Pushed by rempt into branch 'krita/4.3'. Fix loading and saving of document palettes The palettes weren't marked as global on loading, so they were never saved, and the default return value for saving palettes was "false" -- so if there were palettes, but they were not global saving always failed. M +1 -0 plugins/impex/libkra/kis_kra_loader.cpp M +5 -4 plugins/impex/libkra/kis_kra_saver.cpp https://invent.kde.org/graphics/krita/commit/6551d98964c03978c0b9ce926e61498ac901f26e
(In reply to Halla Rempt from comment #13) > Git commit 6551d98964c03978c0b9ce926e61498ac901f26e by Halla Rempt. > Committed on 12/08/2021 at 09:45. > Pushed by rempt into branch 'krita/4.3'. > > Fix loading and saving of document palettes > > The palettes weren't marked as global on loading, so they were > never saved, and the default return value for saving palettes > was "false" -- so if there were palettes, but they were not global > saving always failed. > > M +1 -0 plugins/impex/libkra/kis_kra_loader.cpp > M +5 -4 plugins/impex/libkra/kis_kra_saver.cpp > > https://invent.kde.org/graphics/krita/commit/ > 6551d98964c03978c0b9ce926e61498ac901f26e Awesome, thank you :)
the big question now is... Are we going to make a 4.4.8...
*** Bug 441410 has been marked as a duplicate of this bug. ***
*** Bug 441874 has been marked as a duplicate of this bug. ***