Semi-interesting NOD32 update quirk

Just in case anyone finds this informative or amusing, here's a semi-interesting NOD32 update quirk I "discovered":

Back in late November, I accidentally set my PC clock ahead by almost one month. You see, I sometimes double-click on the clock in the system tray and check a date in the coming month. This creates a problem if one unintentionally clicks OK when they're done, as I did in this case.

NOD32's hourly update continued just fine until I noticed that my clock was wrong. After I changed the clock back to the correct date, NOD32 wouldn't automatically update - it would only manually update.

The log told me that the last time it performed an auto update check was sometime on "December 22" - even though the real date was late November.

I performed manual updates every day for the next three weeks, confident that when the calendar caught up to December 22, the auto updates would start again.

Sure enough, on December 22 the auto updates started up again.

 

I would hardly call that a quirk of NOD.
The next automatic check will be done when the clock hits the time that corresponds with the last check + the interval you set.

Good to know however for those that like to fool around in the future.

Regards,

Pieter

 

Agreed, "quirk" is probably not the best word. It was (perhaps) semi-interesting however because the time of any manual check for an update (clicking "Update Now") does not figure into the equation. That is:

next automatic check = time of last auto check + interval

rather than

next automatic check = time of last check (either auto or manual) + interval

Guilty as charged

Regards,
Optigrab

 

I use the same feature, actually what it shows, is MS should use it as a standard calendar, and place the date and time change feature somewhere else, or have a tab for it

Cheers

 

Pieter_Arntz wrote:

The "quirk" (or, as I would call it, a "security issue") is that a user of NOD32 can essentially disable updating without knowing it and without changing any of the settings internal to NOD32.

Rather than shrugging this off as a lot of other issues are, can we not agree that maybe an alternative method to calculating the update cycle could be used so that this type of thing can't happen?

Most users who look at the update schedule settings see that the update is set by default for every hour. This gives the illusion that the update will occur with respect to a 24-hour interval rather than relying on a specific calendar date.

One alternative, of probably many, could be this:

A flag could be zeroed out after each update and used for the base to add the interval rather than using the specific date of the last update. This would place everything internal to NOD32, and therefore changes to calendar settings external to NOD32 (accidental or otherwise) would have no impact.

Even if my idea is laughable to the programming pros, the point is that this should be looked at as an issue rather than pointing a finger at a user who "fooled around". All known ways to easily, accidentally disable anti-virus software should be taken seriously, especially the ones that can be fixed.

 

Surely a simple method would be for Nod to also look at the version update number, if there is a higher number available it would update.

Cheers

 

Blackspear wrote:

NOD32 has to know when to connect to a server before it can compare the update versions. Without a proper connection interval calculation telling it when to connect to the server, it will never be able to make the comparison (because it will never connect!).

Does that make sense?

See ya.

 

I wrote:

Another:

Use the time-stamp of the update server (assuming it's always kept synchronized to a time server) in the calculation rather than the time-stamp created on the end-users machine. Not as good as some solutions, but fairly simple to implement by substituting the value of a variable for another in the calculation.

Whether the update info screen should show the server time-stamp date or display the end-user time-stamp date is a matter of opinion I suppose. If server stamp, maybe it could be displayed in GMT as a universal time standard. If end-user stamp displayed, maybe it would serve as notice at some point that something is wrong with the computer time settings, yet would have no impact on actual updating ability.

In the meantime, work-arounds (hate those) are:

1. As Pieter said, don't "fool around" with your computer. I like to tho;
2. Periodically assure yourself that your machine time is set properly;
3. Schedule and use a freeware time-sync utility;
4. And for dial-up users, use the "connect-on-dial-up" option. This is only useful if you disconnect and reconnect fairly often, and is of no use to those who use "always-on-connections".