I don't know which version hosed the update functionality but there is something different since at least Opera 57 because Opera 57 automatically updated me to the latest version...

And, of course, the latest version no longer does automatic updates and shows the greyed-out "Check for update" button.

Sigh...

all of the opera 's dir/folders/files and delete the ones in registry.. Where his widows un - installer left off..

Reboot - start new..

(also delete all multi instances of Opera scheduled task)..

the .lock - on the end of the file

And @ bout that time i had to leave.. lol

n e ways

he replied yes and then deleted them (which doesn't hurt @ this point)..

ok the reason for those kinna files are - and this goes back to this post i asked him earlier..

his only reply was - (no-name-opera about 15 hours ago

@nvmjustagirl No. In fact, from the command line, I ran:

C:\Temp\opera\portable\launcher.exe --scheduledautoupdate $(Arg0)
...to see if it came back with any errors. It didn't.)

which that will show in Actions tab (--scheduledautoupdate $(Arg0) in Opera tasks in Task Scheduler

i think he may have multi instances of Opera scheduled task.. but don't think hes
had a chance to check and see yet..

ok so if ya look @ sum logs he posted

you will see this a lot..

Key Word - (Unable to acquire locks!)

This is what i wanna point out..

Is - there is probally multiple entries of scheduled tasks in Task Scheduler

In regular situation there shouldn't be multiple entries of scheduled tasks.

Each installer should keep it clean and have only one task created.. (Unless hes got Beta and Dev installed too)

ok so when multiple scheduled tasks are present situation can occur..

Each tasks first attempts to (Here that key word) - lock temp folder for it's process..

If it is not possible it will try to lock othere folder with (launcher.exe) where it will store temporary autoupdate files..

what am try 'n to say is to look @ the properties of those tasks..

Perhaps they're start 'n the auto updater in the wrong working directory/folders.. Or

they're start 'n with a system/admin user and the environment they're started in has a incorrect temp directory or sumthin..

Note - to cut short i would delete user temp folder, windows temp

all of the opera 's dir/folders/files and delete the ones in registry.. Where his widows un - installer left off..

Reboot - start new..

n e ways thats all i wanna say.. burnout

Hope you can help on this (along with others)..

Now get to work on this challenge !.. *thankyou..

maybe @burnout426 will see this a lil later.. he knows some of the registry data that can be cleaned up

https://forums.opera.com/post/195235 is an example. One can skip the the backing up of bookmarks, open tabs and passwords if not needed.

For testing with standalone installations, I'd install to an "Opera Test" folder on your desktop (or other folder inside "C:\Users\yourusername") and not somewhere outside of "C:\Users\yourusername")

I might create another user account on Windows and see how things work in Opera there (with a standalone installation on its desktop too).

I'd test with another computer on your network if possible to see if it behaves the same or not. I'd test your computer at someone else's house if possible. Sounds like the latter was done in some form.

Don't know about the errors in the log. Don't have access to the autoupdater source to see what the code does.

And about other ISP or Mobile Data?

IpConfig /FlushDNS - If I recall - on Elevated CMD.

So the Opera devs never come around the forums for a bit of troubleshooting, eh?

Any difference if you turn off the VPN? Or if you choose another location?

What about emprtying the temp folder?

[21836:25364:0124/080941.730:80190515:INFO:resource_l10n_handler.cc(101)] Language not in the available languages list: en-US
[21836:25364:0124/080941.730:80190515:INFO:resource_l10n_handler.cc(107)] Trying language from system preferred list: en-US
[21836:25364:0124/080941.730:80190515:INFO:resource_l10n_handler.cc(150)] Retrying after adjustments: en-US
[21836:25364:0124/080941.730:80190515:INFO:resource_l10n_handler.cc(107)] Trying language from system preferred list: en

And please remember these lines come from a just downloaded portable version. So I'm thinking there's at least something wrong there.

However, changing the language does not fix the "COM init failed" or "Unable to acquire locks!" problems. If I only knew what COM init failed meant, it would better help me discover the problem.

@zalex108 Thanks for checking. So just to confirm I understand what you're saying: after you manually click the update button, you have a file \profile\data\opera_autoupdate.log that is empty, correct?

If so, can you please indicate what language you're using? If it's not en-US, perhaps that's another clue (as I posted above, the log shows "Language not in the available languages list: en-US," which is really odd).

Language of System and Opera is EN US.

About the update I'll check, it's the default state after latest update.

CTempoperaportable66.0.3515.44opera_autoupdate.download.lock

Edit:
When I delete the file and re-run the updater, the file is recreated empty/with zero bytes.

do ya have n e files like this

PortableBrowsers66.0.3515.27opera_autoupdate.download.lock

the .lock - on the end of the file

[10972:5992:0124/121601.997:3001781:ERROR:autoupdate_checker.cc(374)] COM init failed
[10972:5992:0124/121601.997:3001781:ERROR:autoupdate_checker.cc(333)] Unable to acquire locks! Download: true, metric: true
[10972:5992:0124/121601.997:3001781:ERROR:autoupdate_checker.cc(137)] Unable to prepare update checker runtime.

This suggests, at minimum, there's a bug somewhere related to the default language. This can't be related to my local environment.

If so, can you please indicate what language you're using? If it's not en-US, perhaps that's another clue (as I posted above, the log shows "Language not in the available languages list: en-US," which is really odd).