I was doing a scan on my nieces laptop and when i checked the results page i saw alot of “unable to scan” i looked through and most of them were from spybot. I searched about it and they said it is normal. But then i found this:
Files that can’t be scanned are just that, not an indication they are suspicious/infected, just unable to be scanned.
Many programs (usually security based ones) password protect their files for legitimate reasons such as AdAware and Spybot Search & Destroy, there are others (and avast doesn’t know the password or have any way of using it even if it did know it).
When you run scans with the above programs and you delete harmful entries that they detect, a copy is kept (in quarantine/restore/backup) in case you need to reverse what you did. These are usually password protected, you should do some housekeeping and delete old backup/recovery/quarantine entries (older than two weeks or so), this will reduce the numbers of files that can’t be scanned.
By examining 1) the reason given by avast! for not being able to scan the files, 2) the location of the files, you can get an idea of what program they relate to. You may need to expand the column headings to see all the text.
If you can give some examples of those file names, the locations and reason given why it can’t be scanned might help us further ?
The images don’t help much as they don’t give the reason, if password protected then there is nothing avast can do about that.
I really can’t see how that can be, whilst there is no guarantee what is on the file type is what is inside the file, but avast can scan a .jpg file. I have also never heard of this reason for not being scanned in the 5 and a bit years I have been on the forums. So there has some other issue here what I don’t know, but again a file that can’t be scanned isn’t an indication of a malicious/infected file; though this one is somewhat strange.
A single detection is normally associated with a False Positive, rather than a good detection. Though it is weird that encrypted files are detected at all as for the most part they can’t be decrypted, so any scan would have to be in the raw data state, so my guess would be that the sunbelt detection was more on suspicion than fact being unable to decrypt the file/archive.
Weird that an mp3 file may be considered encrypted (it is certainly compressed), possibly by the artist to prevent copying, that would also depend on the source it was obtained from.
Whilst it is just the file can’t be scanned issue, if you have any doubt and don’t want to take the risk toy could remove that bonus track/s with the possibly objectionable image references.