APUP 1.4.38 does not even start from shared folder on XP

[older-than-dirt]

The latest APUP.exe 1.4.38 will not even start when it's run from a shared VMWare folder under XP.
No logs, nothing.

The only thing I noticed is that if I run in in the XP VM on its local drive, it creates a temp_bin directory while running and then deletes the directory when it exits. I tried creating the directory manually on the shared folder, but that made no difference when trying to run from the shared folder.

1.4.37 works fine...in all respects

If I can not run APUP on a shared folder, this is going to complicate my life greatly.

Any ideas?

[older-than-dirt]

Can I just update the release list location on 1.4.37 and run it?

[TheAPGuy]

For a short term fix... yes. Just point the older version to the new location.
huh... no logs ehh? So you could be failing somewhere in the environment check or system folder checks. I will bump up the log creation function call to as close to program start as I can and we will see if we get anything.

Edit:
Attached is ver 1.4.40 it is JUST the exe and nothing else. unzip it into an existing apup directory. Save your old apup.exe by renaming it.
Changes:
* Log creation moved as close to start in the program as possible.
* Error code for not being able to detect OS specific directories.
* changes to commandline. /? and /help show a help list.
* /debug added to the commandline list. Does the same as AP's Debug. Not something you should generally use unless you have been asked to. Will add even more data to your log then verbose and make it harder to read.

[DesertJerry]

Downloaded APUP 1.4.40 and unzipped to \AutoPatcher folder.
Everything appeared as it should except: APUP 1.4.38, AutoPatcher Engine 5.7.56 listed in RED. Why is APUP 1.4.38 listed as I have newer? Same for AutoPatcher Engine, presently running v6.0.10.

[ChrisJ]

Downloaded APUP 1.4.40 and unzipped to \AutoPatcher folder.
Everything appeared as it should except: APUP 1.4.38, AutoPatcher Engine 5.7.56 listed in RED. Why is APUP 1.4.38 listed as I have newer? Same for AutoPatcher Engine, presently running v6.0.10.

it's the hash, the beta files don't match the hash listed in the releases list would be my guess. possibly, to prevent this, leave the official files intact, don't rename or overwrite them, rename the beta files instead. actually imo, viroman should rename the betas before he zips them, to prevent this. the files listed in the official releases.list should stay as is, apup.exe, autopatcher.exe, the beta file for testing should be renamed, apup-b.exe, autopatcher-b.exe, whatever, this way you can safely have both in the root, the beta wont get deleted by accident if updater or engine script is selected, will satisfy the main releases list hash. then there's the beta list

[older-than-dirt]

Okay, I downloaded and unzipped and attempted to run 1.4.40.. Same issue so I started to get suspicious and investigated this a little further.. For some reason, versions after 1.4.37 seem to trigger some type of security mechanism in XP, but only when running from the shared folder. I normally update this shared folder from a different virtual machine. When I tried to run apup.exe (1.4.40 & 1.4.38) from a command prompt, I get an "access denied", even though I am running as an admin account. This message doesn't appear when double-clicking from an explorer window. In fact, no message appears at all.

The "solution" appears to be that I needed to extract apup.exe to a local folder on the XP VM and then copy the exe to the shared folder from within the same VM. Now 1.4.40 runs. I repeated the same process for 1.4.38 and now that runs as well. I did not have to do this with 1.4.37 and previous versions.

I apologize for taking your time, but something did change with the exe. I have been using this same VM setup for over 5 years now and haven't changed anything within the last couple of years. But it's now working again, with the change in my procedure.

I can still send a log file if you're interested, but it's probably not going to show anything out of the ordinary.

[TheAPGuy]

Could be the change in using dll files. I have been cutting out un needed dll files and the os might have recognized a change in dll calls. I know that my Firewall will notice this and bring up a box saying something is weird.

As to renaming the beta apps with a "b" or something... I actually never thought of that and its a good idea. Will do so in the future.