https://bugs.kde.org/show_bug.cgi?id=422762
Bug ID: 422762
Summary: Modified file on disk detection often broken
Product: frameworks-ktexteditor
Version: unspecified
Platform: Other
OS: Other
Status: REPORTED
Severity: major
Priority: NOR
Component: general
Assignee: kwrite-bugs-n...@kde.org
Reporter: nfx...@gmail.com
Target Milestone: ---
It appears detection of files being modified on disk is subtly broken. The
impact on the user is often not so subtle. The issue I experience most often is
that switching branches, where some files exist only on one of the branches),
does not reload files properly.
I tried to fix this in my 2018 snapshot of kate (I'm still using that because I
don't like the newer modified files UI). It turns out there are many issues,
some of which definitely still exist in git master. For example take this line:
https://github.com/KDE/ktexteditor/blob/master/src/document/katedocument.cpp#L5007
The createDigest() call is updating m_buffer's digest - even if the file is not
going to be reloaded! Likewise, and this is the problem I'm mostly observing,
if a file is created/deleted it will check against a possibly outdated digest.
I think the main problem is that the invariant, that m_buffer's digest shall
match with the buffer contents, is not properly observed. Actually, you can
wonder why it maintains a digest at all, instead of just comparing the buffer
contents.
When I tried to fix this, I couldn't get it right, but maybe I got confused by
all these buffer types and code paths. I ended up disabling the "clever" reload
behavior, and just prompt the user with any changes that might have happened.
There's also the heuristic to simply reload files if they match a git object
(i.e. without asking the user, even if auto-reloading is disabled). While in
principle useful, I think it's not valid. Just because a certain version of a
file existed once in the git repo, it doesn't mean it'll be easy for the user
to restore the old version. The blob could even be dangling, to be
garbage-collected at git's next opportunity, instead of being connected to a
branch. If this is actually the case (I don't claim to understand the code very
well), this is Bad. If anything, it should check whether the change was
directly related to a certain "git checkout" command (or similar). That means,
auto-reloading would be OK only if the old version was in the previous git
HEAD, and the new version is in the current git HEAD.
And even then, it'd be nice if it didn't auto-reload, but instead the affected
files would show a special status in the reload dialog.
How to reproduce? This is pretty simple. I'll list two cases which are
particularly "common":
A)
- have a branch that adds a large file (maybe at least 40KB on a SSD)
- make sure it's part of the project settings, maybe open the file
- git checkout a branch that doesn't have the file
- click on the file (kate might show a "New File" notification)
- click on another file
- git checkout the first branch again
- the file is not reloaded properly
B)
- delete a file that was opened
- possibly click on another file, then the first file again
- create the file and/or append some text to the file on the shell
- it won't be reloaded properly (sometimes only on the 2nd change)
--
You are receiving this mail because:
You are watching all bug changes.
