Created attachment 110172 [details] Tileset example with a file layer copied 4 times If you duplicate a file layer in a Krita document, when you change and save the source of the layer, only the first instance updates until you close and re-open your master document. The first instance updates every time now, just not its copies. You can use the attached .zip file to test it out. - Open autotile-pit.kra and assets/corner.kra - Draw anything on assets/corner.kra - Save and tab back to autotile-pit.kra: only one instance updates The file layers have transform masks attached but it's the same problem regardless.
I cannot reproduce this here, it updates all instances just fine. The similar bug in 3.x was caused by the thing that listens to file layer changes not recognising the file on the second save due to backups and file name bureacracy, but that cannot be the case here. System info: Krita Version: 4.0.0-beta1 (git bec0891) OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.10.0-42-generic Pretty Productname: KDE neon User Edition 5.11 Product Type: neon Product Version: 16.04
I can confirm it happening on Windows 10 at the least. Krita 4.2 alpha I imagine when you update the source for a file layer, it is only checking one layer, and not going through the entire layer stack to see if other file layers also need to be updated. But I haven't actually looked at the code at all.
Git commit ff338de7354fc170645af1a435267d1024546654 by Wolthera van Hövell tot Westerflier. Committed on 04/09/2019 at 16:02. Pushed by woltherav into branch 'master'. Possibly fix File Layer loading and comics manager page updating on windows. Windows has a pretty slow file system, which means when we check whether our updated file exists, windows hasn't gotten to renaming it yet, making Krita think there's no file at all... So this puts a little bit of a delay in our two checks of whether the file still exists and needs to be readded to the filesystemwatcher again. This currently works as expected on Linux, now we need to test if it works on Windows. Related: bug 410409 M +8 -4 libs/ui/kis_safe_document_loader.cpp M +11 -3 plugins/python/comics_project_management_tools/comics_project_manager_docker.py https://invent.kde.org/kde/krita/commit/ff338de7354fc170645af1a435267d1024546654
I can confirm this is fixed in today's Krita: Next. So for next time, whenever we use a QFileSystemWatcher in combination with Krita, we will need to remember that not just do we need to double check that the file exists(due the renaming to backup system we have), but also to delay this check about 100 to 200 milliseconds, because Window's filesystem is too slow. If you still see this happening with today's Krita: Next, don't hesitate to reopen this report.
Git commit dfbd4763c44ebfd1846fd2d8f26fca74fe99822e by Wolthera van Hövell, on behalf of Wolthera van Hövell tot Westerflier. Committed on 10/09/2019 at 10:32. Pushed by woltherav into branch 'cherry-pick-ff338de7'. Possibly fix File Layer loading and comics manager page updating on windows. Windows has a pretty slow file system, which means when we check whether our updated file exists, windows hasn't gotten to renaming it yet, making Krita think there's no file at all... So this puts a little bit of a delay in our two checks of whether the file still exists and needs to be readded to the filesystemwatcher again. This currently works as expected on Linux, now we need to test if it works on Windows. Related: bug 410409 (cherry picked from commit ff338de7354fc170645af1a435267d1024546654) M +8 -4 libs/ui/kis_safe_document_loader.cpp M +11 -3 plugins/python/comics_project_management_tools/comics_project_manager_docker.py https://invent.kde.org/kde/krita/commit/dfbd4763c44ebfd1846fd2d8f26fca74fe99822e