Version: (using KDE 4.3.4) OS: Linux Installed from: Fedora RPMs "file monitoring" (Dateiüberwachung on my german localized machine) has some major bugs that makes it unuseable Before KDE4 i had written a small "superkaramba" with "tail -n 10 /path/" refreshed every 5 seconds. This worked fine with remote-mountpoints without any errormessages, some seconds after mount the remote-fs it was refreshed. The plasma-applet comes with a errormessage and after mounting the remote-fs the dialog has lost the path, so this is unuseable for tasks like watch server-errorlog from machine withc is not mounted on boot. Even if you mount while booting the system it DOES NOT recognize changes in the remote file and there is no simple way to refresh manually. With KDE4.3.4/4.3.5 the refresh does even not work on local files, i have here messages three days ago in a file that i truncated yesterday evening. inotify is nice, but it should check manually every 5-30 seconds and have a manual refresh in context-menu
the bug was reported for 4.3.4 now we have kde 4.4.2, a whole major and two minor-releases later it´s painful that such things are not working and not fixed over months additionally: if you have a cifs-mount per ssh in the background which lost the connection the widget locks the path so you are unable to reconnect/remount until you kill it.
Would be anybody so kind and fix this after a year or throw the widget away if there is no mention to get it ever working. "Status unconfirmed": I know 4 different machines (x86_64 and i386) which have the same troubles and SOMETIMES after unlock widgets and move it around on the desktop it gets redrawed ONCE
Bug confirmed for KDE 4.6.3. I am not sure when it's been introduced, but it does not work since years which renders the plasmoid - sad to say - practically useless.
Steps to reproduce: 1) Add the widget to the desktop. 2) Create a plain text file with content: "This is a text" 3) Save the file. 4) Configure File Watcher to watch the file. 5) Add some text and save the file (add the dot at the end of the first line!): "This is a text". This is another line. The changed file results File Watcher to show: "This is a text" . This is another line. 6) Delete the last line and save the file. => File Watcher is not updating. 7) Resize the applet. => File Watcher shows the content of the file correctly. Seems like it does only redraw correctly.
What is really frustrating and sad is that NOBODY every replied to this bugreport WTF this is a bug a blind man would see
this is probably because there is no maintainer for this applet, so until somebody steps up and fixes it, there will be very little interest.
pretty - somebody builds anything, it will be included and distributed to the world and nobody ever maintains it? what about security with such a bad attitude and why is nobody reading the fucking bugreports of no longer maintained code and remove non-working and non-maintained crap?
@Reindl: Calm down! The maintainer will ignore it more than ever if we (the users) get angry. Let's give them a bit more time. But, in case it is not fixed for 4.7, I will write a propsal/wish to remove the plasmoid from KDE. Then it will be solved for ever. ;-)
Git commit d3cac726ad979594b574db7782ad1039889735d7 by Shaun Reich. Committed on 28/07/2011 at 05:44. Pushed by sreich into branch '4.7'. Reload when lines were deleted in the file, instead of just..not. Seek the stream back to 0 when we get a dirty notifier and there's no more data. It's *probably* because there were deleted lines. It at least works well for this particular scenario. I believe that's the best way to "go backwards" in terms of a file buffer. BUG: 224772 (cherry picked from commit 64644c35553d58565ab971d2e5a5b0a7d1e3f931) uh..backported from 4.7 to master(am I supposed to add this line?) M +2 -2 applets/fileWatcher/fileWatcher.h M +14 -7 applets/fileWatcher/fileWatcher.cpp http://commits.kde.org/kdeplasma-addons/d3cac726ad979594b574db7782ad1039889735d7
Git commit b9ca09b0f42fab508115e96426c21204c5596f2b by Shaun Reich. Committed on 28/07/2011 at 05:44. Pushed by sreich into branch 'master'. Reload when lines were deleted in the file, instead of just..not. Seek the stream back to 0 when we get a dirty notifier and there's no more data. It's *probably* because there were deleted lines. It at least works well for this particular scenario. I believe that's the best way to "go backwards" in terms of a file buffer. BUG: 224772 M +2 -2 applets/fileWatcher/fileWatcher.h M +14 -7 applets/fileWatcher/fileWatcher.cpp http://commits.kde.org/kdeplasma-addons/b9ca09b0f42fab508115e96426c21204c5596f2b
@Reindl I'd better not see an attitude like that again. Do I see you trudging through thousands of bug reports? Because that's what we have to do. It only requires basic elementary math skills to understand the amount of work we have to do vs. time required to do it vs. how many developers there are, and you'd understand why we don't answer *and fix* every bug report that comes our way, until some time. Consider yourself lucky that Nico was here to make me not want to just blaze over this bug report... (and here's the fix..)
sorry, but 1.5 years for ANY ANSWER for a bug where NO REPORT is needed if only one simple test would have made - what do you expect? if i get such a TRIVIAL brugreport this is fixed in ten minutes and deployed to 200 installations 10 minutes later yes i am developer too and i use the software i wrote by myself what makes the difference, this thing was simply written and orphaned. i would have used a "tail -n 20" with a refresh ervey x seconds, so this works with all sort of files (remote, local) and has no refresh problems > Do I see you trudging through thousands of bug reports? do i make thousands of bugs which never should happen this way like this or the one with a stupid error message "file does not exist" after successful rename of a file in "folder view" which exissts the whole 4.6.x-branch
Reindl: Perhaps you missed the "no maintainer" part? If a bug annoys you that much, then please, feel free to fix it yourself and submit a patch to the bug report AND the correct mailing list. This is *free* software. Very few people are paid to work on it. Thousands of different people have made contributions. Not all of those contributions are perfect. There are bugs. As you are asked, drop the attitude. You don't gain *anything* by pissing off a developer. Or a possible one. If the number of open and unconfirmed bugs offends you, then feel free to join #kde-bugs and ask how to triage bugs. "Unconfirmed" only means that nobody has gone and looked at a report and marked it confirmed. Don't read too much into it. You can work to get more triagers. It is a thankless job, and again, this is free software. *Nobody* is paid to triage bugs. So be nice.
I'm running into this bug in version 4.10.4 on gentoo. Maybe the addon assumes somehow that the file only gets longer? I am using it as a stats display, so all the content may change. If you rescale the addon, it only shows the end of the file. Maybe it should be renamed to "log file monitoring applet", because that's what it does.