[BUG] Delta updates failing



  • I am running the weekly snapshot version of Vivaldi. The past couple of weeks the auto-update has kicked in and attempted to install a DELTA update. Each time it fails. Next start of Vivaldi then downloads the full installer and updates okay. Window 7 Ultimate fully legal and updated. vivaldi installed on D:\WebUtils\Vivaldi My %APPDATA% folders are on E:\Users\mallen\AppData\Local\Vivaldi\ Is this confusing the updates? Or something else? Not sure what is useful to post, so here is a copy of the last few entries in the vivaldi_installer.log that is left in the %TEMP% folder [0930/103751:ERROR:install_worker.cc(209)] Failed creating a firewall rules. Continuing with install. [0930/103751:ERROR:installer_state.cc(617)] Deleting old version directory: D:\webutils\Vivaldi\Application\1.5.604.4 [1007/092112:ERROR:install_worker.cc(209)] Failed creating a firewall rules. Continuing with install. [1007/092112:ERROR:installer_state.cc(617)] Deleting old version directory: D:\webutils\Vivaldi\Application\1.5.609.8 [1008/103548:ERROR:install_worker.cc(209)] Failed creating a firewall rules. Continuing with install. [1008/103548:ERROR:installer_state.cc(617)] Deleting old version directory: D:\webutils\Vivaldi\Application\1.5.618.8 [1015/114602:ERROR:install_worker.cc(209)] Failed creating a firewall rules. Continuing with install. [1015/114603:ERROR:installer_state.cc(617)] Deleting old version directory: D:\webutils\Vivaldi\Application\1.5.626.8 Not sure what firewall rule is failing there. PC is running Eset's Endpoint Security v6 Are there other details of use to people? or a different place I should be posting these bugs?


  • Moderator

    Given that your install is in an atypical location and the user profile is on a completely different drive, Vivaldi probably can't find the proper directories to activate delta updates.



  • I did wonder if that was part of the reason, but the folders are all moved in correct methods that all other applications handle without hiccup. %APPDATA% is E:\Users\mallen\roaming\ and the install path for Vivalidi was set by Vivaldi's own installer.

    Is there any log that would more usefully show what was actually causing the fails?



  • It is still doing this every update. Delta fails, then waits for the next day to install the full patch.

    As no one is interested in the forum, where are bugs supposed to be reported? This is going to be fixable, there is probably just an incorrect assumption of folder names or similar.





  • Thanks for that, I'll go report the bug. Am realising the forum isn't the place for bug reports after my previous posts also got ignored. :D



  • @mallen:

    Thanks for that, I'll go report the bug. Am realising the forum isn't the place for bug reports after my previous posts also got ignored. :D

    Not ignored. More likely that no-one has any useful suggestions.

    To check if it is something with your folders, you could always try installing as Standalone (program and profile on same drive/folder).
    E.g. Install 1.5.638.3 ( https://vivaldi.net/en-US/teamblog/161-engine-update-vivaldi-browser-snapshot-1-5-638-3 ) as standalone then see if auto-update to 1.5.644.7 works.

    Standalone - On license screen select advanced, change folder/drive, select standalone install

    [attachment=4752]Install2-2.PNG[/attachment]

    Then if update works you have useful information for bug report.
    Attachments:



  • Handy idea. Have just tried that out and your test has ruled out the folders.

    I picked a STANDALONE install, didn't register or set as default application.

    Completed install, ran it. It then asked to update. And REPEATED the problem… it downloads the deltas, starts installing, and then spits this a message box that says:

    Software Update
    Failed to extract the update (delta).
    [OK]



  • As this is standalone, do you perhaps need admin rights to install in the drive/folder you picked?

    Otherwise, I'm out of ideas.

    Edit: except maybe your AV (Eset) is blocking it?



  • No - not a file rights issue. Otherwise the real update wouldn't be able to install. (I'm an old git who remembered NT 3.51 so am well versed in he Black Magic arts of NT File Rights :evil: )

    I've had an email response to my bug report. Sent him a log. Well, basically the same log as pasted in here just with an extra entry for the stand alone test.

    Eset - maybe it is upset at the attempt to insert the change. Don't know how that is done, so can't make a comment.

    As I don't know how to reliably always get it to give me the delta download everytime, I don't know best route to take for testing. So I'll leave it for the dev to quiz me. If my brain is awake next time I see a Vivaldi update, I'll turn of the av while installing see if that helps.

    What is comical is sure enough, at the end of the day, the full Vivalidi update downloaded and installed fine. That firewall message is always in the log everytime - success or fail.


  • Moderator

    Any number of 3rd party security apps block Vivaldi from properly functioning or prevent it from being either installed or updated, or both. The 3P security vendors seem unaware that Vivaldi exists - and since it wants to access the internet, and its updates want to change file content, it is surely a virus. Be aware also that "disabling" security software DOES NOT disable it. It just turns off a couple of functions. Hence, if your security software has its fingers in the works, you disable it, the desired function still doesn't work, that's because you can't disable the security software as long as it is on your machine.

    Happy sailing!



  • @mallen:

    As I don't know how to reliably always get it to give me the delta download everytime, I don't know best route to take for testing. So I'll leave it for the dev to quiz me.

    I'm not sure what state it is in after a failed delta update, either. It could do a full update instead of delta or wait for next update then try full update to that version. To repeatedly test, I guess that you would have to uninstall / reinstall an earlier version where update is already available. As least the Devs WILL know how to cope with this (if needed). You could also reply to the bug notification and include a link to this thread.

    @mallen:

    If my brain is awake next time I see a Vivaldi update, I'll turn of the av while installing see if that helps.

    What is comical is sure enough, at the end of the day, the full Vivalidi update downloaded and installed fine. That firewall message is always in the log everytime - success or fail.

    As Ayespy said, turning off AV may or may not help. Probably better is if there a method to approve/white-list an application but I don't know Eset so can't help there. But we're guessing that AV is causing this as the delta works OK for us :)



  • It may say "New Member", but I am not a noob with computers. Far from it. I just don't post on here that often. Am well aware of how to control Eset AV. Though if the AV was blocking this I would expect some level of warning message to be appearing.

    If there was a simple way of being sure that every time I ran a test Vivaldi installer it would grab the delta patch on the next run, then I'd do a few more tests. As currently there is no simple test version like this I will instead wait on the dev to see if he asks for anything more.

    @Ayespy - if you read my issue it is not the general Vivaldi installation that is blocked, it is something specific failing with the delta patch. Eset has no problem with Vivaldi. I don't know how your choice of AV product works, but a "Pause Protection" option within Eset will allow you to work with any infected or damaged file you like as if the AV is off. Alerts and blocks can be stopped during this time. Eset is aimed more at an engineering angle than the nannied home user products like McAfee. (This is getting off thread, we all know how anti-virus works….)

    @TbGbe - yes, I put a link to this thread in the first part of the bug report on the wild chance something useful may get added here. I've also fed over a few debug logs. Also let the guys know I am available to run extra tests if needed.

    Whitelisting isn't going to work as I don't know the name of the installer's patcher tool. That is the only thing that could look "dodgy" to the security product. It clearly trusts the main Vivaldi executable.

    There must be a flag somewhere set by the installer that lets Vivaldi know to try the delta installer, or the full installer. If I could get my hands on that flag so I could toggle it myself then that would allow unlimited tests and thereby let me rule out Eset from the equation.



  • The only other thing I can think of is that a similar problem was reported in the Blog when delta update was released
    See https://vivaldi.net/en-US/teamblog/157-snapshot-1-5-627-3-delta-updates-for-windows

    and the posts by iAN CooG
    Apparently, he raised a bug report (VB-22039) at the time but he was deleting the vivaldi.7z file so it may be different to your problem.

    In the next snapshot blog
    https://vivaldi.net/en-US/teamblog/159-reader-mode-button-vivaldi-browser-snapshot-1-5-633-3
    he had solved his problem

    @iAN CooG:

    As suggested on forum, run this command (vivaldi closed)
    certutil -urlcache * delete
    I had to do this too, at that point I could download the delta update (1.1mb) and everything went all right.



  • I will update this thread when we get to a result. i am working on a few tests with the dev. Could be related to the CooG bug as the log is now showing attempts to run a setup.exe that has never existed on this system. (Unlike the CooG issue, I am not manually deleting anything here)

    Looks more like it is failing to unpack here. Am too tired out with other work to fill in details while the test is ongoing. So concentrating on making sure teh test edv gets the best details at this moment. :)

    Oh - and a fully disabled Eset makes no difference to the situation.


  • Moderator

    Yes. For the delta installer to work, it has to be delta between one version and the immediate next version within that development stream. If a version is skipped, it will fail out, and fall back to the full download.

    As you have probably discovered, the installer for the delta updates is already on your hard drive. The updater will look for it at user/appdata/local/vivaldi/application/(current version number)/installer. It patches the vivaldi.bin files in the .7z archive in that folder with the changes provided by the delta download and then runs the installer which is already resident in the same folder.

    Knowing this will perhaps help you to debug it.



  • @Ayespy - you make some weird assumptions. Of course I am only working between one version and the next. No updates are being skipped here. I do know what a delta is :)

    Specifically in my "StandAlone Test" it is attempting to go from 1.5.638.3 to 1.5.644.7 and it is clear that the correct delta patch is coming in as it is in %TEMP%. It just then proceeds to attempt to patch the wrong thing in the wrong location when looking in the logs…

    I'll stick with working with the dev \ tester guy via email. I don't want to confuse his checks. It is not as if what I am doing is strange, so it will be an error case that will want to be caught by this delta updater. I have a couple of thoughts now which will be tried out. I also know which registry flag to keep deleting to make sure I get the delta every time


  • Moderator

    To be clear, I assume nothing. I was simply stating how the procedure works. Because I noted that it works one way, is not to imply you are trying to do it a different way.

    It will be interesting to find what it is/was about your case that makes delta updates fail for you. In my case, I have one "standard" install and two standalones (snapshot is "standard," and stable and Sopranos streams are standalone) and all of them properly receive and execute delta updates. Hopefully by examining your situation, the developers will be able to make them work even more widely.



  • Looks like it is now solved. B) The detective geniuses at Vivaldi worked it out. I had a Group Policy Object set which blocked Vivaldi from messing around with executable files in my AppData folder.

    This is NOT anything to do with Eset. This was me applying an independent block back in 2013 using CryptoBlocker. That used the Group Policy Object to block any executable getting up to dodgy things in areas that executables shouldn't be. With all the CryptoLocker type encryption viruses knocking around I wanted that extra layer in there and it the first time anything has tripped over it in three years…

    This is what blocked the update: https://www.foolishit.com/cryptoprevent-malware-prevention/

    As I won't be the only person using this GPO a fix has been found to work round this issue.



  • Glad you and devs sorted it out :cheer:

    So it was an Anti-Malware app - just not the one you told us about :P

    I seem to remember seeing a similar protection being offered by Panda AntiVirus and Bitdefender Suites.

    As you say, others may be bitten by this so thanks for posting the result.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.