Incarus

He could also do some testing out of the box if --progressbar is even working for him: http://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs#Progress_Dialogs

Might be a problem with DBus. - Jun 04 2014

The problem is that I can't fix this right now as I don't have access to a linux machine. - Jun 03 2014

This is actually a wanted behaviour. The progressbar is set to for example 1300, if you scan 1300 files. A small file will also count as much as a big file for the progressbar. It would be possibly to change that behavior but it would increase the amount of code. For example you could check how big the single files are (in order of the scanned files) and give the single lines a relative count (the script checks the lines of the log file: 1 more line in the log file is +1 for the progressbar until amount of lines = amount of selected files = length of the progressbar. - Jun 03 2014

the current command to run clamscan in this script is:

nohup clamscan -r --log="$spath"/ServiceMenus/ClamScan/logs/ClamScan_result_$date.log --stdout $real_files > "$spath"/ServiceMenus/ClamScan/logs/ClamScan_$date.log 2>&1 &

we could swap it to something like

if [ "$(pidof clamdscan)" ]
then
nohup clamdscan [...]
else
nohup clamscan [...]
fi

not sure if that is working. - Apr 22 2014

The thought behind using clamscan instead of clamdscan is that not everybody is running or using clamdscan. Not sure if at the mean time something changed about that, but it was at least not easy back in that time to set up clamdscan, at least clamscan was running out of the box.

A possible fix for this would be to let the script check if clamdscan is running and if yes to prefer that one. - Apr 22 2014

So let's see what the problem is here. The script actually checks the amount of lines in the file

"$spath"/ServiceMenus/ClamScan/logs/ClamScan_$date.log

each scanned file creates exactly one new line in that file, so if the amount of lines in the file == amount of all selected files the progressbar should be 100% (or x of x files).
Does the mentioned file exist on your computer (is it creating while scanning)? - Apr 22 2014

Thanks for your Feedback. I hope that I can fix this bugs in the next days but I can not longer maintain the script due to a couple of reasons.

Feel free to fork this project and to maintain your own script, I also changed the license to CC BY (now without SA). - Dec 02 2013

I tried updating the permissions, hope it will be fixed now. - Jun 18 2013

Hello and thanks for the Feedback, I currently have no Linux machine available to test and fix this, but I think I will fix it the next days. - Jun 18 2013

Thanks! I will add it in the next release. - Sep 18 2012

I hope I fixed it now (2.5.6) and didn't break something with the file permissions (I had to do it in Windows) - Sep 16 2012

Hello and thank you the patch. I currently have no access to a linux-machine to test it but I'm gonna add it as soon as possible - Sep 10 2012

Thanks for the feedback.
Yeah, it didn't work for me either and I was really surprised, cause it did before.

Hope everything is fixed after that release ;) - Apr 19 2012

Found several errors in the script, hope to fix it tomorrow - Apr 18 2012

Nice, thank you! :) - Feb 24 2012

That is a ClamAV issue and could have several causes. Try updating the virus signatures with freshclam, if that doesn't help you will find a lot suggestions on the internet. - Feb 23 2012

Hello, and thank you for your feedback.
First you can find out more about that issue by looking in the log file. I would advise you to look in those files (you can find them under /home/USERNAME/.kde/share/kde4/services/ServiceMenus/ClamScan/logs/).
If you can't find something conspicuous try to manually run clamav on the selected file/directory with "clamscan -r /PATH/TO/FILE". If clamscan will output an error here it would be a clamscan issue. I guess it is a permission error. - Feb 23 2012

Thanks! - Feb 23 2012

I updated that, thank you! - Feb 04 2012

There was a problem with kde-apps.org.
The downloadable version of the script should now be v2.4 - Jan 23 2012

Got it fixed. My own script didn't work for me until I realised that my usb-stick folder contains a whitespace and that my script is not able to handle that.
I fixed the whitespace issue in the latest release so I can deliver now the modified clamscan.desktop file in the next version - Jan 18 2012

That is interesting.
I currently experiment with a modified .desktop file in that directory. As soon as this works as I want and after some testing I could add it to this script and to the installation routine - Jan 16 2012

I am not happy with both solutions,
"kde4-config --localprefix"
and "kde4-config --path services"

The first one only returns "/home/USER/.kde/", the second "/home/USER/.kde/share/kde4/services/:/usr/share/kde4/services/"

The first one is unlucky, because the service menu path could differ so "/home/USER/.kde/" + "share/kde4/services" could go 404.
The second one have to be reduced, I'm using "echo ${path%:*}" to do that, which is not the best solution but at least it works.
In theory I need a syntax which only returns the user service menu path "/home/USER/.kde/share/kde4/services/".
My second problem is, that the .desktop file can not run a sh file in the same directory (like EXEC=sh abc.sh). I'm not sure but I think I saw scripts there this or something similar worked. If I'm able to get this to work only the install.sh file will be affected by the first problem. - Jan 03 2012

Of course, corrected! Thank you ;) - Dec 28 2011

*changes.

Thank you for reporting, issue is now fixed in the installation routine. If the services path is not the default path (and I hope that is rare) the installation script will replace the paths in ClamScan.desktop. I also replaced absolute paths in ClamScan.sh with relatives.
Not sure if there is another way to fix that - if you try to install it without install.sh and your .kde path is not the default one you could encouter problems. - Dec 27 2011

Okay, the mentioned changed should fix that. I will release a fix later this day. Thanks! - Dec 27 2011

Hi,
I reviewed the complete source code and come to the following conclusion - correct me if I'm wrong:

There are two common locations for servicesmenus, on my machine (kde4-config --path services):
/home/USER/.kde/share/kde4/services/
and
/usr/share/kde4/services/

For my script I'm using the /home/USER/.kde/ (~/.kde) path because you can write in it without superuser-rights - not to mistaken with /usr/share/kde4/ (!).

However, I will try to completly use relative paths (kde4-config --path services) instead of absolute paths (/home/USER/...) in my next release, thank you!
- Dec 27 2011

Thank you! - Dec 19 2011

Added, thank you! - Dec 18 2011

aww, I Forgot to comment that. Thanks for the translation, I added it ;) - Jun 29 2011

Thank you for the Russian translation, I adopted it as it is. - May 12 2011

The Installer is amazing!

I like the idea of creating an easy to use and intuitive installation software.

Would be stunning to see that project as installation software for unixoid systems like 'Inno Setup' in Windows. - Jan 28 2012

We could create our own project to make sure, that even KDE got a powerful and intuitive virus scanner. - Jun 29 2011