When you export an *.PSD file to a drive on a network, Krita will hang. Reproducible: Always Steps to Reproduce: 1. Create image. Any image. Paint, draw, whatever. 2. Export the PSD file via "Export..." 3. Recoil in horror as Krita no longer responds, giving you the infinite circle of doom. Actual Results: Krita becomes unresponsive, have to terminate the program. PSD file is nor exported, and creates a corrupted PSD file. This also can be reproduced in 2.9. Expected Results: An exported PSD file, ready to go. This is done on a Windows 10 machine (surface 4 pro) with a mapped network folder. A workaround is to export the PSD file onto a local drive and copy that file to the network drive; the PSD export works completely fine when exporting to the local drive.
Hi, Thanks for your report. I wonder if it's related to https://bugs.kde.org/show_bug.cgi?id=357132 . I tried to reproduce that bug using the network drives at work, but there I didn't have any problems. I'm also just not clear on how this can happen... We're writing the data first to a temporary file in your temp dir, then copy that file, but we don't have any special or fancy code for that, we just use what the platform gives us.
Okay, I've tested saving psd, kra and png over the network (shared my public folders on my desktop to my laptop) and that all worked fine. What kind of setup is your network drive?
It's my main art folder on my desktop, actually. I am not using a Homegroup (since there was another one on the network already, thus preventing me from making one...oh, WIndows) so I just used the "Properties -> Sharing -> Share" option. Could edit and save images just fine but when I try to export PSD that's when the issue arises. (Well whaddaya know. Just as I was finishing commenting this, I just did one more test with a simple image, a 1600x1200 image with a couple scribbles on it just to confirm the bug with absolute certainty. It hung for a good long minute and I was going to close Krita but it -actually succeeded-. Opens and closes just fine. I am going to run a couple of tests with a couple of images that I know where the issue surfaced. I'll be back with the results.)
So, here are those test results! hardware: Surface 4 Pro (Core i5/4 GB Ram/128 GB SSD) image: edgarref.kra size: 15.4 MB (6100 x 2500) export start: 10:25 AM PDT ...10:31 AM: still exporting... export end: 10:33 AM Result: Holy cow, an 8 minute export time!? The kra save barely goes over 10 seconds. Opening the psd did not take long. image: feeskypokefat.kra size: 17.8 MB (3400 x 2600) export start: 10:56 AM ...11:09 AM: still going... export end: 11:12 AM As a control, I will export on the Desktop as well. This is saving to another laptop on the network; I expect a slower time since it's a laptop with a mechanical drive: hardware: Core i7 4770k 3.5 ghz, 16gb DDR3 RAM, 128 GB SSD (not used, but instead the hard drive is a Western Digital Black 1 TB mechanical drive, SATA) Additional note: I started this while the other export was happening. The CPU itself hardly was being used so I figure the impact would be minimal. edgarref.kra export start: 10:59 AM 11:09 AM...still going export end: 11:12 AM Based upon the above results, it appears that it is indeed not an application hang, but merely a -MASSIVE- performance decrease when a PSD file (and only a PSD file) has to be exported over the network.
Well, the only problem I can imagine is that PSD saving code uses file seeks while saving... I'm not sure how we should fix that though...
I thought we still saved to a temporary file and then on success copied it over -- but now that I look at the code again, that seems to have disappeared at some point :-( I'll look into it.
Git commit 189daca58291cf6d3443fdc53eac6d579c66086e by Boudewijn Rempt. Committed on 16/08/2016 at 13:46. Pushed by rempt into branch 'video-export-rebased'. Save to a temporary file, then copy the result over on success I thought we were already doing this, but apparently that only was done for remote urls, back in the days we still supported that. The temporary file is saved in the tmp dir, and then copied over. We even make a safety copy of the original file if it exists before doing the copy. This should make saving over network drives faster and more reliable, as well as saving in general more robust. Related: bug 357132, bug 355726 M +63 -17 libs/ui/KisDocument.cpp http://commits.kde.org/krita/189daca58291cf6d3443fdc53eac6d579c66086e
Git commit 3f138209f96cc34a72a135e440609e45633e4ae7 by Boudewijn Rempt. Committed on 16/08/2016 at 13:51. Pushed by rempt into branch 'master'. Save to a temporary file, then copy the result over on success I thought we were already doing this, but apparently that only was done for remote urls, back in the days we still supported that. The temporary file is saved in the tmp dir, and then copied over. We even make a safety copy of the original file if it exists before doing the copy. This should make saving over network drives faster and more reliable, as well as saving in general more robust. Related: bug 357132, bug 355726 M +63 -17 libs/ui/KisDocument.cpp http://commits.kde.org/krita/3f138209f96cc34a72a135e440609e45633e4ae7