Bug 378147 - File layer only updates once
Summary: File layer only updates once
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: 3.1.2
Platform: Other Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-27 08:52 UTC by Nathan GDquest
Modified: 2017-09-12 16:55 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
File layer not updating after the file on the right was saved (191.13 KB, image/png)
2017-03-27 08:52 UTC, Nathan GDquest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nathan GDquest 2017-03-27 08:52:44 UTC
Created attachment 104754 [details]
File layer not updating after the file on the right was saved

Steps:
1. Add a file layer
2. Modify the source of the file layer and save. The file layer updates.
3. Redo step 2. The file layer isn't updated anymore.

I tried with different file types and the result is the same. It will only update if you close and reopen the document that contains the file layer. See the attached image.
Comment 1 Nabil Maghfur usman 2017-08-25 19:12:19 UTC
I can reproduce the bug in the krita 3.2.1 appimage, running on debian testing.
Comment 2 T.R.O Nunes 2017-09-12 13:33:05 UTC
Can confirm still happens on Windows 10 on ver.3.2
Comment 3 wolthera 2017-09-12 16:06:36 UTC
This is caused... by the backups, strangely enough. QFileSystemWatcher considers saving to the backup and then saving a new file to the old path the same as deleting the path.

https://stackoverflow.com/questions/18300376/qt-qfilesystemwatcher-signal-filechanged-gets-emited-only-once
Comment 4 wolthera 2017-09-12 16:24:29 UTC
Git commit 829876d88b5fbdc1a79d235d11a459753a1fd81d by Wolthera van Hövell tot Westerflier.
Committed on 12/09/2017 at 16:24.
Pushed by woltherav into branch 'master'.

Basically, this was caused by the backups.
Krita handles backups by saying "ok, you, old file, rename to backup,
and new file, you become the url of old file". This renaming is what
signals QFileSystemWatcher, and because it is a rename, it removes it
from the list of watched files.

So what we do is that when we get our change in, we check if the file
exists and is still being watched, and if so we readd it.

M  +4    -0    libs/ui/kis_safe_document_loader.cpp

https://commits.kde.org/krita/829876d88b5fbdc1a79d235d11a459753a1fd81d
Comment 5 Halla Rempt 2017-09-12 16:55:39 UTC
Git commit ce183f5050c5b66fe89b0818ede64d6e068ad6ad by Boudewijn Rempt, on behalf of Wolthera van Hövell tot Westerflier.
Committed on 12/09/2017 at 16:55.
Pushed by rempt into branch 'krita/3.3'.

Basically, this was caused by the backups.
Krita handles backups by saying "ok, you, old file, rename to backup,
and new file, you become the url of old file". This renaming is what
signals QFileSystemWatcher, and because it is a rename, it removes it
from the list of watched files.

So what we do is that when we get our change in, we check if the file
exists and is still being watched, and if so we readd it.

M  +4    -0    libs/ui/kis_safe_document_loader.cpp

https://commits.kde.org/krita/ce183f5050c5b66fe89b0818ede64d6e068ad6ad