[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
On Saturday 24 Jan 2004 9:10 pm, David Bell wrote:
On Saturday 24 January 2004 6:58 pm, Neil Williams wrote:On Saturday 24 Jan 2004 2:17 pm, David Bell wrote:I have just carried out a first scan using BitDefender AV. The log below includes an <I/O errors> entry. What does it mean?Usually happens when a file is changed during access.Thanks Neil, I browsed around their site and couldn't find anything to help either. I'll see what happens next time that I do a scan. I have it installed on my SuSE v9.0 box which is set up for SMTP/POP3, and carried out an update, after install, before the first scan. It seemed to work well - or did it! Their FAQ sheet included in the download is very
Ah, right. If it's installed on SUSE then there is also another reason for I/O error reports - although it's not an error as such. If you ran it as root and scanned the entire system, a lot of files in /dev will report I/O errors - [root@xxxxxxxx neil]# cat /dev/hdc cat: /dev/hdc: Input/output error That's predictable, /dev/hdc is the cdrom drive - it ain't mounted. Therefore, there may be nothing to worry about - what bitdefender is reporting as I/O errors is simply Linux protecting you from doing something really daft - scanning a non-existent filesystem. It would be better if BitDefender used a bit of logic and checked files in /dev/ before trying to open them. /dev/hdc reports 0 bytes with ls. Instead it just appears to pass the OS error report directly through to the user report.
helpful towards using the programme, but doesn't include anything on error messages or the like.
It's not really a BitDefender error message, it's BitDefender reporting on an OS error message that it didn't know how to categorise/avoid.
However (OT), On the dark side of the planet I've lost absolute faith in Windows type AV programmes after Macafee discovered 2 nasties Trojan.exe (SennaSpy 2001) and Worm.exe(NewAOL)) which AVG failed to detect on two PCs.
When the OS is infected, you can't blame it when the infective code changes OS behaviour to try to hide. Linux/Unix rootkits do the same by 'customising' ls and other system commands to avoid detection. Finding a virus after infection isn't the easiest of tasks on any OS if the virus/trojan/worm writer has the knowledge to mask the program effectively. The problem in Windows is that every script kiddie with a grudge can write a malicious agent. The only solution is prevention, not fighting a rearguard action. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00097.pgp
Description: signature