As specified in the header, I can't get krita to save png, gif, or jpg files. Unsure if other formats are effected, but I can confirm that PSD and kra export seems to work. When attempting to export to these formats, krita instead displays this error message, which simply says the image will not save but does not specify a reason: https://www.dropbox.com/s/8aaavwpk078nqcn/1d6eff0668014832d0c6e815423cdb47.png?dl=0 Unsure of why this is happening, please let me know if there's any additional information I could provide.
I can't reproduce this issue with the build you specified. I tried also 7c63972 and the 4.0.3 release. They all save the files fine, no matter which format I choose.. For a moment I suspected it might be related to Dropbox syncing (since the file path in your screenshot looks like a location synced by Dropbox), but I also tested with saving in a Dropbox sync location and they all saved fine for me. Here are a few questions: 1. Is it intermittent or does the file always fail when saving in png, gif, or jpg? 2. What if you change the file name and/or save location? 3. Had it ever worked in a previous version/build? 4. What is the file format of your original source file and does it use any uncommon features? 5. Does it happen if you just create a new file, make a few strokes and attempt to save the file in these formats?
1. the conditions under which this happens seem consistent, but I'm finding that export does seem to work outside those conditions. I'll elaborate below. 2. Changing the filename doesn't seem to make a difference one way or the other. 3. Unsure, I upgraded to nightly in hopes of fixing a specific issue, and I haven't tried to export under previous builds yet, as far as I can recall. Unrelatedly, the uninstaller seems to be missing for some reason, which has impeded any attempts at downgrading. 4. source file is .kra, and uses alpha inheritance, vectors, and layer groups. Here's the file in question, if it helps at all: https://www.dropbox.com/s/eof4w6t3tj1rdvc/1-4.kra?dl=0 5. Whether or not the file is new seems to have no influence, though exporting either one directly to my desktop seemed to work, so the main influencing factor seems to be save location as opposed to file contents. Upon further investigation, the issue seems to be that my entire dropbox folder was somehow marked read-only, and that was preventing the Krita from exporting in those formats to those specific folders, as resetting the permissions has brought back the ability to export the files to those folders. This is still extremely bizarre, as other programs seemed to be able to export to those folders fine, this is the first time I've had such an issue with Krita either, and one would think that a pure permissions issue would have effected PSD and kra files as well. I'm not sure if this issue is "solved" since this still seems to be strange behavior on Krita's part, but that's probably up to your discretion, and at least I can export again.
I don't really get it. On Windows you can't just set a folder to read-only. One would have to mess with the security ACL permissions to do that, and I doubt this is what you touched. If you simply right-click on a folder and check/uncheck the checkbox that says "Read-only (Only applies to file in folder)", it really only changes the read-only attribute of the files inside the folder but not the folder itself. The initial state of the checkbox also doesn't indicate whether the files inside are read-only or not. If I set a file as read-only and then attempt to save over it in Krita, the native file dialog actually prevents it from happening. Even if I disable the native file dialog, Krita shows the message box with the reason "file.png cannot be written to. Please save under a different name". I've tried a few things but couldn't get Krita to show the message box with an empty reason. Do you have anything in mind? If not I am afraid I can do nothing about it.
I can't particularly say that I know what was going on with that either, or why ticking unticking the "read only" box in my dropbox folder's properties made any difference, if that actually had anything to do with it. Now I'm not even sure if that's the case, because I attempted to export moments ago and the issue is still happening, which makes me think that something ELSE I'd done in the meantime might've temporarily fixed the issue and the stuff with the read-write permissions was unrelated. It seems that I can still export to any folder outside of my dropbox folder just fine. I can't say for certain that the dropbox client is causing the issue somehow, but shutting it down seems to solve the problem. Starting the dropbox client up again seems to cause the issue to start happening again, but not immediately. I'm not sure if it's just kicking in after several minutes, or if it's allowing a few exports to go through before it starts happening, but shutting down dropbox immediately restores export functionality to krita. Maybe changing the read-write permissions caused the dropbox client to treat the folder differently for a short time, and that's why messing with those properties had an effect? Can't really do much more than speculate there. Additionally, I should have investigated this before, but Krita produces one file that looks like these, on each failed export: https://www.dropbox.com/s/fhnzu788jn66zdz/dda5742f045de3ed97334ab2df27f31c.png?dl=0 Removing the additional extension at the end of the filename seems to reveal a properly exported file. This suggests that krita actually is managing to export, but can't complete the process and properly name the file, for some reason. Here's a copy of one of the files in question, if that's any help: https://www.dropbox.com/s/trhgws7sc50q6mu/1-4.png.Ya7988?dl=0 Is there some sort of log I could dump that might provide more information? Because I'm not sure if there's much more I can do to investigate here otherwise.
The behaviour you describe matches what bug 392408 was about, though I really had the impression that it was fixed in both the nightly builds and 4.0.2/3. I will either need to be able to reproduce it myself or see a Process Monitor capture of things happening. Since I am not able to reproduce it, would you be able to get a capture with Process Monitor? You should make the capture with the filter "path contains 'C:\Users\Will\Dropbox\[something]'" and then attempt to save a file in the folder [something] (pick a name and create the folder beforehand).
(In reply to Alvin Wong from comment #5) > The behaviour you describe matches what bug 392408 was about, though I > really had the impression that it was fixed in both the nightly builds and > 4.0.2/3. > > I will either need to be able to reproduce it myself or see a Process > Monitor capture of things happening. Since I am not able to reproduce it, > would you be able to get a capture with Process Monitor? You should make the > capture with the filter "path contains 'C:\Users\Will\Dropbox\[something]'" > and then attempt to save a file in the folder [something] (pick a name and > create the folder beforehand). Apologies for taking so long to reply, but I've finally been able to get Process Monitor to work well enough for me to get you the capture you requested. Here's a link to the log: https://www.dropbox.com/s/07yocyxhasmlz73/Logfile.PML?dl=0 And in CSV format, on the off chance you need that: https://www.dropbox.com/s/tbb5juwuzhyo7um/Logfile.CSV?dl=0 I hope this helps!
Hi Beatrice, thanks for the reply! However, I can't seem to find any log items of a file save attempt in that directory. Are you sure you set the filter as "Path contains C:\[...]\savetry" and not "Path is C:\[...]\savetry"? It has to be "contains" to also include entries related to the files in the folder. Can you please try to get a log again? Also make sure you did try to save the file inside that folder.
(In reply to Alvin Wong from comment #7) > Hi Beatrice, thanks for the reply! > > However, I can't seem to find any log items of a file save attempt in that > directory. Are you sure you set the filter as "Path contains > C:\[...]\savetry" and not "Path is C:\[...]\savetry"? It has to be > "contains" to also include entries related to the files in the folder. Can > you please try to get a log again? Also make sure you did try to save the > file inside that folder. Yeah, I may have had the filter set "is" instead of "contains". Sorry about that! Here's some new links, hopefully correct this time: https://www.dropbox.com/s/94maywr5aqh48rf/Logfile.PML?dl=0 https://www.dropbox.com/s/a6tejw6w5ba0oy0/Logfile.CSV?dl=0
Thanks, this capture does show the problem. I'll need to investigate it for a bit.
Hi Beatrice, would you allow the capture and the information from it to be mirrored and shared with developers of other projects (e.g. Qt)?
(In reply to Alvin Wong from comment #10) > Hi Beatrice, would you allow the capture and the information from it to be > mirrored and shared with developers of other projects (e.g. Qt)? Yes, I'd be perfectly okay with you mirroring and sharing these captures!
For reference, I've commented on this issue on the Qt bug: https://bugreports.qt.io/browse/QTBUG-57299?focusedCommentId=407313&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-407313
POC patch to Qt which should solve the issue (side effects unknown): https://phabricator.kde.org/P235
Okay, I've made a Krita build with this patch. It can be downloaded from https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 Debug symbols (probably not needed): https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 Please test it :-)
(In reply to Boudewijn Rempt from comment #14) > Okay, I've made a Krita build with this patch. It can be downloaded from > > https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 > > Debug symbols (probably not needed): > > https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 > > Please test it :-) Also, please make a Process Monitor capture when testing so I can use it to verify the behaviour of Dropbox.
(In reply to Alvin Wong from comment #15) > (In reply to Boudewijn Rempt from comment #14) > > Okay, I've made a Krita build with this patch. It can be downloaded from > > > > https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 > > > > Debug symbols (probably not needed): > > > > https://www.dropbox.com/s/yrovg6felfbw957/krita-qtbug394376.zip?dl=0 > > > > Please test it :-) > > Also, please make a Process Monitor capture when testing so I can use it to > verify the behaviour of Dropbox. Opps sorry, Beatrice you can skip testing this build because I made a mistake in the patch. I've updated the patch, please wait for a new build to test with.
New build: https://www.dropbox.com/s/sf6q3aiw0g7a1ru/krita-qtbug394376-2.zip?dl=0
(In reply to Boudewijn Rempt from comment #17) > New build: > https://www.dropbox.com/s/sf6q3aiw0g7a1ru/krita-qtbug394376-2.zip?dl=0 Can confirm it to be working with this build.
(In reply to Sebastian from comment #18) > (In reply to Boudewijn Rempt from comment #17) > > New build: > > https://www.dropbox.com/s/sf6q3aiw0g7a1ru/krita-qtbug394376-2.zip?dl=0 > > Can confirm it to be working with this build. Can you make a Process Monitor capture?
(In reply to Alvin Wong from comment #19) > (In reply to Sebastian from comment #18) > > (In reply to Boudewijn Rempt from comment #17) > > > New build: > > > https://www.dropbox.com/s/sf6q3aiw0g7a1ru/krita-qtbug394376-2.zip?dl=0 > > > > Can confirm it to be working with this build. > > Can you make a Process Monitor capture? Sadly, don't have time for that right now. It just worked for me to save a new krita file to dropbox (saving existing ones was working for me already). And export it as .png to dropbox as a new file.
*** Bug 392408 has been marked as a duplicate of this bug. ***
*** Bug 396846 has been marked as a duplicate of this bug. ***
I've got a different workaround here: https://phabricator.kde.org/D15184
i still have this issue myself ,i always have to close dropbox its really annoying Saving krita files is never an issue tho,only export
The workaround was committed: https://phabricator.kde.org/R37:c4186f6ac0e463ad0b27f1997d12d89b1742d678