AW: Windows error 32
rev at nonsanity.com
Thu Jan 6 10:00:50 EST 2011
A tool I've used on Windows to good measure is Unlocker . If you manually
try to delete something that can't be deleted, it will tell you why, what
task is responsible, and let you sever the connection so you can continue in
your wanton destruction of data unimpeded.
~ Chris Innanen
On Thu, Jan 6, 2011 at 7:55 AM, Richard Gaskin
<ambassador at fourthworld.com>wrote:
> 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
>> 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
>> and keep it like that, knowing that windows keeps so much trash behind
> 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
> 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
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode