InstallAware

I have noticed multiple folders called mia*.tmp (~100) in my %programdata% folder. E.g.

Directory of C:\ProgramData
...
01/05/2018 08:25 PM <DIR> miaB333.tmp
05/06/2018 11:47 PM <DIR> miaB684.tmp
08/02/2018 09:41 PM <DIR> miaB846.tmp
22/05/2018 09:05 PM <DIR> miaBAED.tmp
16/02/2018 01:04 AM <DIR> miaBBD4.tmp
27/07/2017 12:31 AM <DIR> miaBC93.tmp
16/10/2017 09:55 AM <DIR> miaC04F.tmp
...

Each folder contains various data and sub-folders to do with IA setups.
Since these folders end in 'tmp' are they temporary folders which can safely be deleted?
How did the folders get there in the first place, and is there a reason why IA is not automatically deleting them if they are temporary?

thanks
paul g

Update 26 Jan 2019:
Still no explanation for this issue. However as of around about Oct 2018 (probably I updated IA then) also some newly produced folders with the names ~1, ~2, ~3, ... containing similar contents to the miaxxxx.tmp folders.

Directory of C:\ProgramData
...
24/10/2018 02:34 PM <DIR> ~0
24/10/2018 08:22 PM <DIR> ~1
23/01/2019 06:11 PM <DIR> ~10
24/10/2018 08:28 PM <DIR> ~2
...

Hello Paul,

Did you ever get a reply on this, or a reason why it is happening?

I am seeing the same issue here in house as well as on some of my client's machines. Some of these folders are empty, and some have extracted setup files in them. Deleting them didn't seem to affect the uninstall of those products.

From testing, that folder is created when IA extracts the compressed setup program (I have a single self-extracting install). I haven't been able to reproduce the issue of the folder left behind; I've tried cancelling the install at various points, installing a previous version and having a later install version "upgrade" the older version. So far that directory is cleaned up. But at some point, it wasn't and I would like to know why.

hi sheri,
no i never did get a reply. However it seems that they are not causing any harm except for taking up space, and the fact that they have a .TMP name would indicate that they should be able to be safely deleted.
paul g

Paul,

Thanks for the follow-up; I'm still looking into this as it bothers me; hate leaving extra data around on the client's machine.

If I find out anything I'll let you know.

Hi all,

I'd be interested in solving this issue also, as I don't like the customers PC to keep those files, eventhough it's only space wasting.

Looking forward to hearing from you.

Has the origin of these files ever been resolved? If not, I have some additional information.

1. These are not the folders used to cache the main install. those have a GUID name and are removed when the program is uninstalled.

2. On my system at least, these mia*.tmp files appear to contain the contents of filebags and program prerequisites. These folders are not removed when the program is uninstalled however, leaving over 2 GB of junk in the ProgramData folder.

We also have the problem that all the mia*.tmp folders and also the {guid} folders are never remove. Does anyone have a hint, what's wrong?

astech wrote:We also have the problem that all the mia*.tmp folders and also the {guid} folders are never remove. Does anyone have a hint, what's wrong?

It would be helpful to have some more details, as for example:

- which IA version has been used to generate the package?
- does it happens always when or this is limited to certain conditions (as; first time install, when setup fails, when upgrading, when patching and so on)?
- is this behavior reproducible with a very minimal test project created from scratch?

Since this whole issue is still bothering me and still doesn't seem to have a solution, and it doesn't happen with freshly created projects:

I wonder, where do Persistent Variables get stored?
Could it be, that they're stored in this mia*.tmp folder, and that this could be the reason why these folders won't get deleted after deinstallation?

Do you have any chance to send me a minimal project with the steps required to reproduce the issue?

Has there ever been a resolution to this issue? I'm looking to upgrade our copy of InstallAware, and the people above me want to know if this issue has been resolved, since some of our customers are not happy about the extra GB of space being taken up by these files?

FrancescoT wrote:Do you have any chance to send me a minimal project with the steps required to reproduce the issue?

As I wrote:

pfennig wrote:...it doesn't happen with freshly created projects...

Our projects are huge. They have grown over many years and versions. Without having a clue what could cause these folders to not get removed, it's like searching for ... what? ... in a haystack.

If the info helps, it doesn't happen anymore under Windows 11, but continues to happen on all previous Windows versions.

We had the same problems of multiple mia.tmp folders in %PROGRAMDATA% that got not deleted after installation.

For us we found this as the reason:

We started the installed application (located in the installation folder) right from the last setup dialog. The started application accessed multiple files which then where hold in access by the started application.

The setup then tried to delete the temporary mia.tmp folder which it could not.

After a lot of analysis and tests, we discovered that the reason for this behaviour was because of the setup creates NTFS hardlinks per default. Because of this hardlinks, the files in mia.tmp and installation folder referred to the same file in the filesystem.

The running application accessed sample.bpl from installation folder for example. Because of the hardlink this was the same file as in some subfolder of the mia.tmp folder. Due to this the file in mia.tmp was also in access and could not be deleted from mia.tmp and so the folder itself also could not.

We set this variable in our setup script:

Set Variable NATIVE_HARDLINK to FALSE

For us this solved the problem of the mia.tmp folders could not getting deleted after installation.

Thank you for investigation this issue. I can confirm this behaviour using Process Explorer.
Starting die freshly installed application from the last setup page, even the application exe-file is accessed inside a mia*.tmp folder, in our case including language files also. The command line shows the path one would expect, and the icon pinned to my taskbar is active and provides the properties accordingly. So the correct exe is running and this funny connection to the mia*.tmp folder seems completely unnecessary..

I'm not really happy with your suggestion for a solution. According to the help file setting NATIVE_HARDLINK to FALSE has side effect that seem unpredictable when trying to restore the installation. I wouldn't want to touch this.

But I think IA now knows what to look for and can take care of disconnecting the installed application when starting it directly from the setup.