SimpleUpdater — Rev. 10.69 / 2016/06/19

[Marco]

Looks like the script is failing with this beta, http://www.xyplorer.com/xyfc/viewtopic. ... 921#p85921
Based on what I can see, the last modified time is the one of 12.30.0216, which in turn has a correct 2 May last modified time. Some strange swapping...

EDIT: zip file available for download appears to be identical to 12.40.0000 stable
zip sha512 8884f068c4716f0d9cb2d16ea3a99e628b00546f18355272368194437dc908f7
exe sha512 1619c1783be55e18a2c8ad74c44ef517f48cc7a72b6e46eb8278d999e2c058e3
So no problem whatsoever script-side

[klownboy]

Thanks for the update Marco, I was wondering what was going on with Beta 12.40.0001. I manually DLed what I thought was the beta and it was the same...no beta.
Thanks,
Ken

[binocular222]

@Marco: There should be SimpleUpdater's version number noted inside script file (i.e in opening comment). I can hardly tell which version I am using now

[Marco]

You're right, thanks for the suggestion. Will add it from the next build onwards.

[Borut]

Since several beta versions after 12.90 I am experiencing the following:

At the point where downloaded and extracted files are to be copied to their final positions, an info-dialog shows up, informing me that a file already exists (CatalogDefault.dat, most probably the first file tried). By clicking on OK the story ends, in a sense that the old files are *not* being overwritten with the new ones. The old XYplorer version then restarts. The script "thinks" that the update has been completed successfully.

I suppose that this:
- does not have anything to do with XYplorer itself,
- does not have anything to do with SimpleUpdater.xys either, since it has not been changed since April.

On my WinXP machines current Windows Updates have been done recently. This seems the most likely cause to me (in the absence of better ideas).

Anyone else with this strange experience?

[Marco]

Is there any other process that might be locking those files?

[Borut]

I am not aware of any. XYplorer closes correctly before that point (and I am running only one instance).

I must admit that I am lost now: I have now removed CatalogDefault.dat from the xyplorer folder prior to the update try. However, I am still getting the error message (from German, the upper one: Copying... Copying "CatalogDefault.dat" into... (target path is not visible); lower one: Error while copying file or folder. The file already exists.)

I notice that at that time the Extraction folder appears to be empty. Strange. (Where are the extracted files?)

[Marco]

Borut, I'll stay tuned to this topic too, http://www.xyplorer.com/xyfc/viewtopic. ... 2&start=60
Maybe things are related.

[Marco]

Also, if you want you can join the Archive and see if with older betas the same bug happens. I can't test on a XP SP3 system before October.

[serendipity]

Also, if you want you can join the Archive and see if with older betas the same bug happens. I can't test on a XP SP3 system before October.

I did not read the entire thread but for me it worked without problems all along on my XP SP3 which had the ole32 related bug (now fixed).

[Borut]

OK Marco, I believe I have found the cause (at least approximately). First of all, it seems to have nothing to do with Windows Updates - I have noticed that different machines behave differently (on one the script succeeds, while not on the other) although they both are on the same Windows Update status.

In my temp directory, I have found 99 directories named in the following way (German Windows):

Code: Select all

Temporäres Verzeichnis 1 für XYplorer.zip
Temporäres Verzeichnis 2 für XYplorer.zip
...
Temporäres Verzeichnis 98 für XYplorer.zip
Temporäres Verzeichnis 99 für XYplorer.zip

After deleting them manually, the Simple updater completes the process perfectly again.

I am not sure in which phase of the update process such a temporary directory is being created - I presume that it is during the decompression, since these actually contain the XYplorer files contained in the zip.

My hypothesis is, that after the 99th directory no new one is being created (for some mysterious reasons), which then somehow leads to the collision, which prohibits the completion of the process.

[Marco]

Thanks for the debug Borut!
When you say "temp directory", what do you refer to, Windows %temp% or the temporary folder where I perform the zip extraction (and which should be deleted after a successful update)?
Because in the first case I'm afraid there's not much that I can do - Windows should handle its temporary folder(s) properly by itself.
BTW, you're talking about XP, right? I use 7 regularly, and after an XY update nothing in my %temp% about XY is left over.

[Borut]

Yup, I am on XP and the location is %TEMP%.

So, bad bad Windows, seems not to be clean in that respect.

It would be interesting to know if there are other WinXP users of Simple Updater script and if they can find similar directories left over after the script run.

[Marco]

Yep, I join the plea.

[nerdweed]

Though I am on Windows 8, I have observed a similar thing on Win XP earlier.

A friend was unable to open excel files from outlook - apparently he had too many excel files in temp directory. Cleaning up had fixed it.