AW: Windows error 32

[Richard Gaskin]

Tiemo Hollmann wrote:

> I can't provide a solution but can tell, that I see from time to time the
> same behavior, using innosetup. Everything is deleted, except the empty
> appfolder. Innosetup even has a section to define objects to delete after
> everything, but this doesn't works also from time to time. It is the same,
> if you uninstall the app from the control panel or the uninstaller from the
> appfolder. The people in the inno uselist say, it's a windows problem and
> there is no solution what I can change in innosetup. So I gave up some time
> and keep it like that, knowing that windows keeps so much trash behind it...

Thanks for chiming in, Tiemo.

I don't know much about the innards of how InnoSetup works, but here the 
issue was apparently resolved by changing the working directory.   We 
just went through a rather substantial round of testing on a wide 
variety of Win systems including all three modern flavors (XP, Vista, 
7), and in all cases the uninstall works well as long as we change the 
working directory from the original to something else before deleting 
that original.

This hypothesis appears to match what the OS is reporting, error 32 
being "resource in use by another application", the other app being the 
file manager.   The file system maintains a working directory property 
for each process, which is more or less what the LiveCode engine is 
using with its internal representation of that, "the default folder".

On some Win systems (95 and 98; couldn't find this option in XP) there's 
a field in the Properties window for an executable to set the initial 
default folder.  That pretty much does what we do in script when we "set 
the default folder to...", changing the working directory for the process.

That was the clue that led me to explore changing the default folder, 
and indeed so far it seems to be the answer, at least for my uninstaller.

The core issue is that the copy of the app which does the actual 
installation was being launched by an app that, like any LC-based app 
(and most others AFAIK), had its working directory set to the one it's 
in.    Since the copy is launched by that original, it's seen by the OS 
as a sort of child process of that original, and the OS maintains its 
record of that original working directory as a resource that's still in 
use, even after that original app had quit, as long as that child 
process (the copy) is running.

FWIW, Wise Install has always deleted everything you tell it without 
exception in my 10 years of working with it, so while it's more 
expensive than InnoSetup it may be a good option if that level of 
tidiness is important to your customers.

As frustrating as computers can be sometimes, I try to maintain the 
understanding that, being deterministic systems, it should be possible 
to solve any problem with them.  The trick is to identify the 
differences between the working and non-working states, and then make 
whatever changes are needed to make the non-working state mirror the 
working one.  Sure, Windows has issues, as do Mac and Linux, but most of 
the time they work as described in their APIs.

In this case I had the advantage of a working state, Wise Install, so I 
had the confidence it should be possible to solve this.

That said, this app has only been in the wild a few days now, so it's 
probably fair to acknowledge that there's a chance we may encounter a 
system on which our uninstall doesn't work completely.

But in the meantime this one seems resolved, and it might be useful to 
know if InnoSetup is changing its working directory before attempting to 
delete the folder in question.  It may be necessary to change that 
directory before launching the copy in tmp - that's what I did here, and 
while I don't know if it would also work if I changed after launching 
the copy, so far doing it as I have seems to solve the problem.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv