SimpleUpdater — Rev. 10.69 / 2016/06/19

[LittleBiG]

Ok, I got it. Unfortunately is a bug within XY and the unset command, not the script itself. Gonna tell Don in the Bug reports. Did it start behaving like this only today?

No, not today. Somewhere on the road of 13.80.

[Marco]

Ok, thanks to Don ( ) this is fixed with 13.80.0108

For those who use the user button I published on the first post: simply perform the update with the usual left click. After that, trigger once again the script via a left click on the user button. The fixed unset in the _Terminate section will be called and will clear the leftovers.

For the rest: you have to manually delete the permanent variable

Code: Select all

$strA_yLb2oLZnSvh3

in Scripting > Permanent Variables. Then you should be able to proceed as usual. After the update, call once again the script, and the fixed unset in the _Terminate section will be called and will clear the leftovers.

[LittleBiG]

Thanks, Marco, I am happy to have this great script again!

[klownboy]

Thanks Marco for pointing out the perm variable issue and to Don for making the fix. I was wondering yesterday why I had a huge collection of perm variables not just for the SimpleUpdater script.

[Marco]

An heartfelt thank you to Sıtkı Evrenkaya : now SimpleUpdater is available in Türkçe too!

[oblivion]

I set this up on a (fairly normal) portable install last night, seemed to work fine (although I missed the sense, initially, of the "set this to NOT the channel" stuff, which, when you don't want the beta releases, is a touch ambiguous) but on my netbook, with what I thought was a similar setup, I can't make it work.

I get this:

The system cannot find the file specified. (C:\utils\XYPlorer\Data\Scripts\SimpleUpdater\HTTP_response.txt)

This system has Comodo AV on it (my desktop has a different AV), and although I've done my best to tell it to trust XYPlorer and all its offspring, I'm still seeing the occasional complaint about the .vbs file that presumably gets created by the script and then run -- I guess because it's a new file every time, it looks like something to worry about every time.

Does anyone else use Comodo AV and know how to get round the problem? Or am I barking up the wrong tree and I need to increase the delay in the script to 30 minutes or something ridiculous?

[Marco]

Hi Tim, I use CIS so I know the beast you're talking about. CIS changed the way it sees Internet connection from vbs file starting from version 6: in previous versions it saw an Internet connection as coming from the very vbs file, now it sees it as coming from cscript.exe (the vbs interpreter). So, a first suggestion is to create a firewall rule for cscript.exe. Also, CIS Defense+ is definitely a pain, and I disabled it. So have you tried disabling it for yourself and see what happens?

[bdeshi]

SimpleUpdater does nothing if no updates were found. Should at least show a message saying so!

[klownboy]

Sammay, it does display a message in the status bar below so you may have missed it. It says something like, "XYplorer is already up-to-date."

[Marco]

Yup. This:

Immagine.png

Depending on the folder you're located in it may be visible for a shorter time (eg. in a folder with disk activity and autorefresh on).
PS: in earlier versions a message in a popup window was shown, but I felt like it was too intrusive (you had to click OK to dismiss it), while I belive that such "non message" should not interrupt your workflow.

[bdeshi]

I saw it (for a sec ). I ran the script from <xyscripts>, and because it creates a folder and deletes it again, the message is quickly cleared by XY detecting the deletion and refreshing. Executing it from any other location is perfectly fine. Thanks.

[oblivion]

So, a first suggestion is to create a firewall rule for cscript.exe. Also, CIS Defense+ is definitely a pain, and I disabled it. So have you tried disabling it for yourself and see what happens?

I've tried disabling the whole of CIS and the script still fails in the same way.

I'm not terribly familiar with configuring Windows Firewall but I added a "allow everything" rule for system32\cscript.exe and the script STILL fails.

And although I've d/l the new version by traditional means, now there's something to test the script with I'd really like to get it working before giving up and going back to the old ways

[later]

I've run through the simpleupdater script in stepping mode and tried to watch what's going on. The text file it's failing to find doesn't look like it's being created -- and I didn't notice anything happen when the line that executes the .vbs script that (presumably) creates the textfile is run immediately before the textfile should exist.

Because I'm stepping through it, it presumably can't be a delay issue.

Is there anything I can do to check why the relevant bit of code (which I think is this bit:

Code: Select all

cmd /c $vbs_interpreter //nologo "$http_checker_path" "$download_url" "$last_modified" "$http_response_path"
COMMAND;
 run "$command", , "2", "0";

isn't working?

[Marco]

Ok, please try this mini-script. Just create a new folder, put it into it and run. Now that the DOS window is visible, could you please post its content?

[oblivion]

Now that the DOS window is visible, could you please post its content?

Sadly, the DOS window was only visible for half a second. The created .vbs file happened, though.

There used to be a Windows setting somewhere that controls that behaviour... I'll see if I can find it.

[highend]

just replace "cmd /c" with "cmd /k".

The window should stay open.

Content?