Bug 311582

Thanks for the report and for the precise steps, I could reproduce this with an up-to-date 4.9 branch checkout. Following the example of bug 211472, I should probably write a unit test for this one as well and then let David fix it. I'll try to do it when I find some time. But if anyone else wants to try, please go ahead!

Similar behaviour here, only worse; F5 doesn't work as expected.
I'll see if I can send more details later.

I have this, too, in KDE 4.8.5 on Slackware64-14.0. It seems to similar to https://bugs.kde.org/show_bug.cgi?id=244163.

I tried to come up with a unit test, but did not succeed so far, my test always passes.

Interesting: the bug does not happen if the folder is renamed from the Terminal panel.

(In reply to comment #2)
> Similar behaviour here, only worse; F5 doesn't work as expected.

This is most likely a different bug.

(In reply to comment #3)
> I have this, too, in KDE 4.8.5 on Slackware64-14.0. It seems to similar to
> https://bugs.kde.org/show_bug.cgi?id=244163.

Does not look similar to me. The present bug is about failing to update the view after a folder is renamed. Bug 244163 is about no updates happening at all (which I cannot reproduce). BTW, note that KDE 4.8.5 is quite old. Usually, reporting bugs is only useful if you use a rather recent version.

Created attachment 76696 [details]
KDirLister unit test

OK, I managed to make the test fail by using KIO::moveAs() to do the renaming (which is just what KonqOperations does). I hope that my test is correct and helps to find the root cause.

Git commit 74b0d33afefc916de7c5a2129704a9e4cf8a3952 by David Faure.
Committed on 25/01/2013 at 13:20.
Pushed by dfaure into branch 'KDE/4.10'.

Fix dirwatching being stopped when using KIO::moveAs().

CopyJob calls stopDirScan to avoid notification storm (it uses KDirNotify
i.e. DBus to notify of the operation instead), and forgot to call
restartDirScan in the precise case of direct renaming. Moving a '}' fixed it.

With many thanks to Frank Reininghaus for another great unittest!
FIXED-IN: 4.10

M  +6    -5    kio/kio/copyjob.cpp
M  +56   -0    kio/tests/kdirlistertest.cpp
M  +1    -0    kio/tests/kdirlistertest.h

http://commits.kde.org/kdelibs/74b0d33afefc916de7c5a2129704a9e4cf8a3952

(In reply to comment #4)
[...]
> (In reply to comment #3)
> > I have this, too, in KDE 4.8.5 on Slackware64-14.0. It seems to similar to
> > https://bugs.kde.org/show_bug.cgi?id=244163.
> 
> Does not look similar to me. The present bug is about failing to update the
> view after a folder is renamed. Bug 244163 is about no updates happening at
> all (which I cannot reproduce). BTW, note that KDE 4.8.5 is quite old.
> Usually, reporting bugs is only useful if you use a rather recent version.

Well, "quite old" is relative. It was quite new, when Slackware-14.0 was released, which was less than four months ago... 

Unfortunately, due to the never-ending deficiencies of Akonadi I refrain from upgrading KDE monthly. Every time I do it costs me more time and effort and nerves than if I would migrate to a completely different (non-KDE) email client.

Although I understand, that developers prefer to work on the most recent version instead of haunting bugs in older releases, I also thought that it might help you to track down, since when the bug existed, and what change might have introduced it.

(In reply to comment #7)
> Unfortunately, due to the never-ending deficiencies of Akonadi I refrain
> from upgrading KDE monthly. Every time I do it costs me more time and effort
> and nerves than if I would migrate to a completely different (non-KDE) email
> client.

I fully understand that, and I also appreciate your willingness to help. But please also understand that reports about bugs in old versions don't help us much if we know that major changes and bug fixes have happened in this area in the meantime.
 
> Although I understand, that developers prefer to work on the most recent
> version instead of haunting bugs in older releases

I wouldn't say that we "prefer" to do that. "Hunting bugs in older releases" just makes no sense if we cannot reproduce the bug in the latest release, and it appears likely that the changes that have happened in the meantime have fixed it.

> I also thought that it
> might help you to track down, since when the bug existed, and what change
> might have introduced it.

This might help indeed if you can say precisely 
a) which was the last working version, 
b) which is the first buggy one,
c) you can provide simple steps to reproduce the problem, and
d) the developer can also reproduce the problem on his/her machine.

I know and understand that quite well, of course, and as far as possible I try to include all useful information and nothing else in my bug reports and change requests. I really know how hard it is for you to reproduce and track down bugs in any but the most recent versions --- as I said, I had  a life as software developer myself.

The problem for me as a *user* is, however, that I have no realistic chance to satisfy all your requirements for an optimum bug report. E. g., I just don't know, if a bug has been fixed in the most recent release candidate of the next KDE SC incarnation. For the bug here, it seems, that it has been fixed in an version that hasn't been released, yet. So no chance for me to see, if the fix really solves the problem (but, of course,  I have no reason, not to trust you, saying so!).

For bugs like this one I cannot see it in the changelogs, and, frankly, I don't follow the commits. Here I have to rely on the comments of developers, when they say, a bug has been fixed in a more recent version. And if that's the case, all is good for me. I am not demanding that the bug must be fixed in the version I currently use, when I know that it is probably gone, just as soon as I upgrade KDE (or my system along with it).

What I do, however, is to research the bug database, of course, before I file a new bug. And in this case I found a couple of bugs that seemed similar to what I saw, and theses other bug reports referred to different versions, including quite recent ones. But from the descriptions I was not quite sure, if they were really the same. That was my motivation to add my description, along with steps to reproduce it for the version of KDE I have (currently 4.8.5).

If I knew, I would give you all the requested information, but unfortunately, I don't know a) and b), but I think I gave you c), not sure about d). If I can provide this sort of information, I always do, of course!

Anyhow, the good news is, that the bug is apparently fixed in KDE 4.10, which is soon to be released, I guess. Thanks for making KDE a better desktop with (almost ;) ) every new release!

No need to continue the discussion, as I clearly understand your position, and I think you can understand mine. I'll continue to try my best to support KDE with bug reports and change requests, and wherever possible I'll include the information you request. Just that I cannot promise, that I'll always be able to do so.

Thanks for the detailed reply! Just let me add that I do realise that it's not easy to say from a user's point of view if a bug report for an 'old' version will be useful. If you're in doubt, just add a bug report/comment and let us handle the rest. There are certainly some bugs left in KDE 4.10, maybe even some which are related to updating the view after any changes in the folder, which is a very complex thing.

(In reply to comment #10)
> Thanks for the detailed reply! Just let me add that I do realise that it's
> not easy to say from a user's point of view if a bug report for an 'old'
> version will be useful. If you're in doubt, just add a bug report/comment
> and let us handle the rest. 

Yep.

> There are certainly some bugs left in KDE 4.10,
> maybe even some which are related to updating the view after any changes in
> the folder, which is a very complex thing.

I can imagine that, given the many abstraction layers in KDE today... Good luck!