Bug 426701

Thanks for reporting!
Since it looks like you're using 4.2.9, can you please check version 4.3.0 or, preferably, Krita Plus from the website if it isn't fixed in the newest version already?

(In reply to Tymond from comment #1)
> Thanks for reporting!
> Since it looks like you're using 4.2.9, can you please check version 4.3.0
> or, preferably, Krita Plus from the website if it isn't fixed in the newest
> version already?

I was under the impression that Krita auto-updates, but if there is a 4.3.0 then I'll test that and report back.

(In reply to Tymond from comment #1)
> Thanks for reporting!
> Since it looks like you're using 4.2.9, can you please check version 4.3.0
> or, preferably, Krita Plus from the website if it isn't fixed in the newest
> version already?

I uninstalled my Krita and bought and installed the Steam version. The same error message came up right now.

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.

Do you think it's possible that it always happen when you have multiple pages saved nearly at the same time? (More than one).

Git commit 44a0f2258fe301245bf979bf9df3c907c876cf22 by Agata Cacko.
Committed on 16/10/2020 at 00:28.
Pushed by tymond into branch 'master'.

Fix Comic Manager race when updating multiple files

Before this commit, in case of updating multiple files at once,
for example when copying files into the `pages` directory to
overwrite existing ones, the following would happen:

signal filechanged(file1) -> url = file1 -> wait 200ms ->
    slot updatefile (update `url` file) -> url = ""

signal filechanged(file2) -> url = file2 -> wait 200ms ->
    slot updatefile (update `url` file) -> url = ""

When you update both file1 and file2 at once, a race condition
would happen and the exact sequence on the timeline would look more like
this:

signal filechanged(file1) -> url = file1 -> signal filechanged(file2)
   -> url = file2 -> wait 200ms -> slot updatefile (update `url` file,
   which is now `file2`) -> url = "" -> slot updatefile (update `url`
   file, which is now... an empty string

Then the plugin would crash on `realpath()` because the url is empty
and there is no check for that.

This commit fixes the behaviour by keeping a list of files to update.
That way in the first phase when lots of `filechanged` signals arrive,
all files to update are saved into a list and then after 200ms popped
from the list and updated one by one.

The most elegant solution would be to have QTimer keep the url,
it would be also possible to make the updatefile slot just update all
files from the list and return if the list is empty, but it's not
necessary because the signals will eventually arrive in the correct
number.

M  +36   -31   plugins/python/comics_project_management_tools/comics_project_manager_docker.py

https://invent.kde.org/graphics/krita/commit/44a0f2258fe301245bf979bf9df3c907c876cf22

Git commit ec086e45378ec8bb5111d3bf564bb56f548978b5 by Agata Cacko.
Committed on 16/10/2020 at 00:40.
Pushed by tymond into branch 'krita/4.3'.

Fix Comic Manager race when updating multiple files

Before this commit, in case of updating multiple files at once,
for example when copying files into the `pages` directory to
overwrite existing ones, the following would happen:

signal filechanged(file1) -> url = file1 -> wait 200ms ->
    slot updatefile (update `url` file) -> url = ""

signal filechanged(file2) -> url = file2 -> wait 200ms ->
    slot updatefile (update `url` file) -> url = ""

When you update both file1 and file2 at once, a race condition
would happen and the exact sequence on the timeline would look more like
this:

signal filechanged(file1) -> url = file1 -> signal filechanged(file2)
   -> url = file2 -> wait 200ms -> slot updatefile (update `url` file,
   which is now `file2`) -> url = "" -> slot updatefile (update `url`
   file, which is now... an empty string

Then the plugin would crash on `realpath()` because the url is empty
and there is no check for that.

This commit fixes the behaviour by keeping a list of files to update.
That way in the first phase when lots of `filechanged` signals arrive,
all files to update are saved into a list and then after 200ms popped
from the list and updated one by one.

The most elegant solution would be to have QTimer keep the url,
it would be also possible to make the updatefile slot just update all
files from the list and return if the list is empty, but it's not
necessary because the signals will eventually arrive in the correct
number.


(cherry picked from commit 44a0f2258fe301245bf979bf9df3c907c876cf22)

M  +36   -31   plugins/python/comics_project_management_tools/comics_project_manager_docker.py

https://invent.kde.org/graphics/krita/commit/ec086e45378ec8bb5111d3bf564bb56f548978b5

@jeyek - the bug has been now fixed and backported; which means that you can wait 24h from now and then go to krita.org and download the version that is called "Krita Plus" from the website. Please do check and confirm if the bug is fixed for you there.

The Krita Plus version should be rather stable but there are some new features that don't appear in Krita 4.4.0, so take that into account when making a decision whether you want to use it for everyday usage.

Despite this bug being fixed in Krita Plus it has returned in Krita 4.4.1

Hi, it happens in Krita 4.4.1 because Krita 4.4.1 has very minimal set of bug fixes over Krita 4.4.0. It was released like a week or two after the release of 4.4.0 and it was because it was an emergency release, not a normal release. Hence it doesn't have this bug fix. Please either use Krita Plus or wait until next Krita (which appears to be named Krita 4.4.3 because we used up 4.4.2 in Windows Store? Sorry, I know it's confusing a bit :) But the next version should be around a month and a half from now, it will be just the next big version with a huge list of bug fixes and some new features).

No worries. Thanks for the clarification. :)