Brutal Write Attempts to Hard Disk when AV Updates ?

Hello :slight_smile:

I use AV manual update. When I updated the AV after about one or two weeks, Comodo AV uses brutal hard disk write attempts. After close monitoring of the program’s memory, I/O attemps and hard disk space, it seems that for every single piece of anti virus definition update, Comodo deletes the entire antivirus database and re-writes from the scratch with the new update.

I noticed that when Comodo updated after about couple of weeks, the total write atttemps seemed to exceed about 12 gigabytes. Is this a good way of programming ? Isn’t there any other better way to update Antivirus Database without “hurting” the hard disk that much ? Is it possible to make a suggestion to Comodo Developers about this ?

Thanks :slight_smile:

I think this should change also. I think the way they have it now is ok if you use your computer everyday and you don’t miss a lot of updates, but it does not work if you don’t update a lot.

It should work like this I think.

CIS checks for updates, it downloads 50 updates that you missed, then it takes the whole AV definition file loads it to RAM ( while at the same time creating a copy in a temp folder and deleting the original one from the scanners folder), in RAM it writes the updates to bases.cav file and then after all 50 are written and it checks to make sure that the update is good (though SHA1) it then proceeds to write it back to the original scanners folder. While all this is happening it has the copy of the original bases.cav file in a temp folder just in case the first attempt to write the definitions does not work it will not have to re-download the whole update again, it will just try to write it to the bases.cav file you had before it started updating. Once the definitions are written back to the hard drive and are checked, it will delete the back up it had.

Thanks :slight_smile:

Glad to hear that it’s going to change :slight_smile:

wait I never said it was going to change, I said how it should change.

My suggestion would put more of a load on the RAM and CPU and less on the hard drive but I think it can be mitigated, if lets say it would automatically limit it’s cpu usage to 25% while updating the user would not notice it, updates might take a little longer but it would free up the hard disk and it should still be pretty fast.

The Dev’s need to work on it that’s for sure.

Oops, sorry I missed the word “Should”.

It’s good if it limits 25%. If it’s a multi processing system, perhaps Comodo uses one processor 100% and let other processors for user ?

Another question, while this AV update in progress after loading it to RAM, does Antivirus still work ? I.e., when anrivius is being updated, does Comodo have the ability to detect for viruses in case an executable file is launched ?

well it could, all they would have to do is leave a copy of the original bases.cav in the scanners folder until the one is ram is updated and verified, then it could delete it and write it back to hard drive almost instantly.

I was also thinking how about instead of having one big bases file it could have multiple small updtes in one folder for each update. So instead of having to write it to a big file it could just add the update to folder and use it almost instantly. Then when the computer is not being used it could use the time to consolidate those small files back into the big file. So basically it would clean up after itself when the computer is sitting idle.

I don’t think it’s ever going to change. People have been complaining about the inefficient update method for years. If they haven’t changed it yet, I doubt they ever will.