Krita doesn't save changes, but acts like if it did save. Hours of hard work have lost because of this and not just work but TIME! If krita saved file to an other -for me- unknown location, it would be very good to know where. Or if there is a solution for this problem, or somehow I can recover my work, I would be very thankful. I saved by simple save, not save as. It is a .kra file. Modification date of file also haven't changed, so Krita hadn't saved or not over this file... There was NO error message when saving or when opening the file.
Hi, David! A couple of times we got reports that people opened a .kra file directly from Firefox and start working in it. If it was your case, please try to check your windows' temporary directory. The file might be saved there (unless you cleaned the directory up yet).
I think that this is about read-only files, like you get when opening something from a browser. This might indeed be broken and needs checking.
When I try to do ctrl + S on a read only file , it behaves as if it is saving, but the title bar clearly shows a star and "(write protected)" is suffixed after the document name, this is the only indication that it is readonly. it doesn't show dialog box or warning message. The user who somehow missed the title bar change wouldn't know if the file is readonly. The actual saving does happen though, even if the file is marked readonly for user. Even if the owner is "root" in linux systems a user can overwrite the file. This gets confusing as the title bar shows a star and "write protected but the file actually gets saved . And again when you try to close the file , it prompts for saving, when you click yes then the file is saved and the file permission is restored to read and write for the user. I tested with a file whose owner was root and group + others only had read permission. After making some changes the files ownership and permission were reverted back to user. I think 1) Krita shouldn't change file ownership and permissions (somewhat serious and dangerous) 2) It should have proper warning that the file is just read only 3) It also shouldn't do the save when the file is read only, it may offer save as option so that user can save a copy of the file. P.S. I am marking this critical as files owned by root can be changed. In future when we scripting ability this can turn into a nightmare in my opinion.
Git commit 2307e466bb2228959c965c28b0ef82b43dd8898f by Boudewijn Rempt. Committed on 28/03/2017 at 10:30. Pushed by rempt into branch 'master'. And use QSaveFile to be smart about the permissions and ownership. Note that this demands a very filthy hack for saving using KoStore: we need to make sure KArchive cannot close() the iodevice, because that aborts if it's a QSaveFile. For other file types, like tiff and exr, we cannot save to io devices, we can only pass filenames to the relevant libraries. For those, add a flag to KisImportExportFilter that IO devices aren't supported, but rather ignored. M +42 -11 libs/store/KoZipStore.cpp M +4 -5 libs/store/KoZipStore.h M +46 -89 libs/ui/KisDocument.cpp M +3 -0 libs/ui/KisImportExportFilter.h M +30 -8 libs/ui/KisImportExportManager.cpp M +0 -1 libs/ui/kis_png_converter.cpp M +1 -1 plugins/impex/brush/kis_brush_export.h M +1 -0 plugins/impex/exr/exr_export.h M +1 -1 plugins/impex/exr/exr_import.h M +1 -1 plugins/impex/spriter/kis_spriter_export.h M +1 -1 plugins/impex/tiff/kis_tiff_export.h M +1 -0 plugins/impex/tiff/kis_tiff_import.h M +1 -0 plugins/impex/video/kis_video_export.h https://commits.kde.org/krita/2307e466bb2228959c965c28b0ef82b43dd8898f
Git commit 9dbf40b7d3b8b70fe0b545bdfd03d74b6cee0ee9 by Boudewijn Rempt. Committed on 28/03/2017 at 10:54. Pushed by rempt into branch 'krita/3.1'. This doesn't use QSaveFile like in master because the structure of the unrefactoring KisDocument save and export code is way too tangled for that. M +93 -92 libs/ui/KisDocument.cpp https://commits.kde.org/krita/9dbf40b7d3b8b70fe0b545bdfd03d74b6cee0ee9