the old bug is back (updates) [BUILD 5.0.393]

LOL I haven’t seen that happen for a while, last time it happened was on an old beta, the UI showing an outdated Avast when it’s actually updated already. Rebooting changes nothing this time ;D I upgraded directly from 377 to 393 with the installer.

I got it back too with Pro.

what a shambles!

I did an install from scratch and don’t have the problem ;D

Greetz, Red.

Just a minor note. Since this is a prerelease anyway, Alwil should get it fixed in the release.

I would think so yeah :wink:

You said rebooting changes nothing?
What does the file \defs\aswdefs.ini say?

Mine says
latest=10012601

Folder 10012700 is there but not pointed to with latest
Manually changed to latest=10012700 but didn’t do anything so changed it back. Needs a reboot? Or a clean install seems to work for others, but they haven’t gone through another update yet.

@ Vlk: I just uninstalled “free” (as mentioned in another thread here, got it back after a system image restore yesterday) to reinstall AIS 5.0.393. So the bad news is I can’t answer your question anymore obviously, but the good news is that I have the current update appearing normally in the GUI. Doesn’t mean much, gotta wait for the next update to tell how it behaves…OK. But I guess an install from scratch instead of an upgrade should fix the issue in most cases.
off topic: firefwall seems to behave much better now, with rules created automatically when config on “auto-decide”. I’ll mention this in another thread I started about the FW.

Mine says this too.
Bug confirmed here. I updated (no clean install) and rebooted. Otherwise, 5.0.393 is working fine.

I should mention that I uninstalled Avast! version 377 the normal way, than used the new aswClear.exe in safe mode, after witch I installed Avast! 393 the normal way.

Off topic : sded and me think that after installation a reboot is needed for things to work properly, although Avast! doesn’t ask for it.

Greetz, Red.

Please send the file avast5\setup\setup.log to my email, I’ll check it.

I installed Pro over Free. The installer removed Free, then installed Pro, but didn’t ask for a reboot then. At least the Sandbox was inactive until I did a reboot manually.

not the same behavior here, installed IS over free, that just uninstalled “free”, prompted for a reboot and that was it as expected. I had to launch the IS setup again after that. Too many differences between “free” and IS I suppose to avoid a first reboot.

Should have clarified, I installed Pro-same behavior as you saw removing Free, booting, restarting the install myself., But no reboot requested after Pro install, no sandbox until I did one. I’ll send Alwil the file.

yeah it’s not new that once in a while a feature doesn’t work immediately after the install, and will after a reboot. happened a few times during the beta testing. I guess there should be a prompt to reboot after a new install, even if most of the time it isn’t needed. Just speaking for “free” and “pro” here. As obviously on IS, a reboot is mandatory for the firewall, first network detection etc…

Yeap, the bug is here! here is the screenshot, when i click in update database, it says is up to date, but the UI says is older. Here is the Screenshot

It’s related to the fact that you had a newer version of the VPS than the one which was included in the package. It’s a problem that won’t happen in the release version.

Thanks
Vlk

just to mention: noticed already a few times that some persistence cache files were kept in the system after an uninstall, and most likely reused with a new install, which is a very good thing as that really speeds things up with a first new scan.

For those that it does affect (not me on the 377 build), would disabling the self-defence module and editing the aswdefs.ini to show the latest version be a work around ?